This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: tree-ssa-sink breaks stack layout


On Sun, Apr 5, 2009 at 11:02 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
>> It is likely possible to paper over the issue for the testcase we have, but
>> this fix-this-single-testcase-with-a-workaround doesn't sound appealing
>> to me if we admittedly know other places in the compiler with exactly
>> the same issue ...
>
> Do we? ?Again, that's not a rhetorical question; I don't know the
> answer. ?Do we have other test-cases showing this problem with other
> passes?

I have created tens of testcases showing PTA analysis bugs, I think
it would be not difficult to create testcases that break with tree
loop invariant/store motion and with PRE (just to name the two
obvious candidates).

>> So, instead of trying to paper over this in tree-ssa-sink.c I would instead
>> suggest to detect "overlapping" scopes during cfgexpand and consider
>> them as merged for the purpose of stack slot sharing. ?This will result
>> in less sharing but be a more robust fix.
>
> Yes, that sounds plausible to me. ?It is indeed detectable if a direct
> (rather than pointer-based) access to a variable has migrated outside
> the lexical scope of that variable. ?Is that's what happening in this
> case? ?I wasn't sure if it was a pointer escaping, or a direct reference
> to the variable escaping. ?Obviously, both could be problems, but we are
> explicitly looking for less-broken approaches here, not right answers...

I suggest to merge all overlapping scopes, not just detect if variable
accesses have been migrated outside their scope (that's not easy - if
you just move a stmt its lexical block does not change, instead if
you scan stmts looking for out-of-order (or unknown) blocks for stmts
then you know sth bad may have happened)

>>> "code doesn't work; debug for a while; looks like compiler is broken;
>>> search web for work-around; rebuild with work-around" is not as as good
>>> an experience as "code works". :-)
>>
>> Heh, but of course we have that all the time with answers like
>> "try -fno-strict-aliasing", "try -fwrapv", etc., so adding another one doesn't
>> sound too bad here.
>
> That's true -- but those cases are for code that isn't strictly
> conforming. ?To a certain extent, we've taken the attitude that it's the
> user's responsibility to write valid C code, and that we can mercilessly
> punish those who don't. ?But, it's only fair, then, that we try hard to
> compile the valid C code correctly. :-)

True.  But there are a lot of existing wrong-code bugs in released compilers
(with small testcases).  It's not that we can fix everything, but providing
a reasonable workaround like -fno-strict-aliasing is something we should
make sure exists (no, I don't really consider -O0 an acceptable workaround).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]