Messages in this thread | | | Date | Mon, 12 Jan 2009 20:55:34 +0100 | From | Bernd Schmidt <> | Subject | Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning |
| |
Linus Torvalds wrote: > > On Mon, 12 Jan 2009, Bernd Schmidt wrote: >> Something at the back of my mind said "aliasing". >> >> $ gcc linus.c -O2 -S ; grep subl linus.s >> subl $1624, %esp >> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s >> subl $824, %esp >> >> That's with 4.3.2. > > Interesting. > > Nonsensical, but interesting. > > Since they have no overlap in lifetime, confusing this with aliasing is > really really broken (if the functions _hadn't_ been inlined, you'd have > gotten the same address for the two variables anyway! So anybody who > thinks that they need different addresses because they are different types > is really really fundmantally confused!).
I've never really looked at the stack slot sharing code. But I think it's not hard to see what's going on: "no overlap in lifetime" may be a temporary state. Let's say you have
{ variable_of_some_type a; writes to a; other stuff; reads from a; } { variable_of_some_other_type b; writes to b; other stuff; reads from b; }
At the point where the compiler generates RTL, stack space has to be allocated for variables A and B. At this point the lifetimes are non-overlapping. However, if the compiler chooses to put them into the same stack location, the RTL-based alias analysis will happily conclude (based on the differing types) that the reads from A and the writes to B can't possibly conflict, and some passes may end up reordering them. End result: overlapping lifetimes and overlapping stack slots. Oops.
Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
| |