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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
