[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 --- Comment #23 from Sandra Loosemore sandra at codesourcery dot com 2011-06-01 17:34:56 UTC --- Draft patch that addresses this bug here: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-03-08 22:50 --- This is the same as bug 39509. *** This bug has been marked as a duplicate of 39509 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-12-16 20:53 --- In a discussion we decided that introducing a __builtin_undefined () that we can assign to variables at the point they die would be the proper way to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #20 from ramana at gcc dot gnu dot org 2009-09-18 07:19 --- *** Bug 41354 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||erik at arbat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 --- GCC 4.3.4 is being released, adjusting target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.4 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-05-10 10:00 --- Another possible solution that was mentioned is to delay stack slot allocation until after scheduling (or possibly later code motion optimizations). Before that stack slots could be represented by their own pseudos (pointers to the base of the stack slots) and conflict analysis could be done on RTL based on life ranges of the memory pointed to by them. A complication is how to recover scope based lifetime rules if the stack slots escape to function calls (but I suggested to do these merging opportunities early on the tree level, during gimple lowering). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51 --- The late stack slot allocation idea will just cause other problems, like missing CSE of addresses. GCC should just get the conflicts right somehow... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #16 from rguenther at suse dot de 2009-05-10 14:14 --- Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout On Sun, 10 May 2009, steven at gcc dot gnu dot org wrote: --- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51 --- The late stack slot allocation idea will just cause other problems, like missing CSE of addresses. GCC should just get the conflicts right somehow... somehow... ;) I don't see how without making the coalescing decisions part of the IL on RTL (and of course see if coalescing is even possible before doing it). What about dropping all MEM_EXPRs for accesses to coalesced variables? With the new memory-model that should be enough, without it you'd also need to make the use alias set zero. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #12 from dougkwan at google dot com 2009-05-10 00:56 --- Created an attachment (id=17840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17840action=view) C test-case for the same problem on x86_64 and i386. The original C++ test-case does not crash on x86_64 and i386. I compared the generated code and found that ARM EABI requires constructors to return values. That is not common and certainly is not the case on x86_64 and i386. So gcc generates very different code on both targert very early on. The C test-case was created based on the lowered C++ code in the middle-end. It crashes with just -O2 on x86_64 with both 4.3.1 and 4.4.0; it crashes on i386 similarly with 4.3.1. I did not test 4.4.0 on i386. Unfortunately this does not crash on ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-10 02:09 --- Created an attachment (id=17843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17843action=view) type-correct version This is a type-corrected version of the same C testcase. Two structs are different types even if they contain the same members, so the casts and accesses as 'struct a' where the object really was 'struct b' are not valid. That can be solved by modeling the same as in C++, via proper subobjects of base-type. This testcase still exhibits the abort() with -O2 with 4.3.2 on i386 and x86_64. It doesn't fail with current trunk, but most probably for the same coincidence since a-i merge. I haven't checked 4.4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #11 from dougkwan at google dot com 2009-05-09 01:21 --- We saw this also in gcc-4.3.1 on target arm-none-eabi. -- dougkwan at google dot com changed: What|Removed |Added CC||dougkwan at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #9 from sandra at codesourcery dot com 2009-04-03 12:54 --- After the merge of the alias_improvements branch to trunk, the test case no longer compiles incorrectly at -O1. Is this coincidence, or a real fix that addresses the underlying problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #10 from rguenther at suse dot de 2009-04-03 13:23 --- Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout On Fri, 3 Apr 2009, sandra at codesourcery dot com wrote: --- Comment #9 from sandra at codesourcery dot com 2009-04-03 12:54 --- After the merge of the alias_improvements branch to trunk, the test case no longer compiles incorrectly at -O1. Is this coincidence, or a real fix that addresses the underlying problem? I believe this is a coincidence. Can you investigate what the difference is? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #2 from matz at gcc dot gnu dot org 2009-04-01 11:45 --- The old stack slot sharing problem. stack slot sharing really wants to look at scopes to determine if stack variables can share the same space or not (stack variables, not registers, those are all top-level). But sometimes tree transformations do fiddle also with stack variables (loads/stores) and hence can move references to variables outside of their block tree. The block tree either needs to be fixed up, or the stack slot sharing needs to look at other information than block scopes to determine lifeness bounds. Both of these things are probably best done in cfgexpand, and as I'm working on expanding from SSA form I might try to do something here (though the variables in question are exactly those which are _not_ in SSA form). -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 14:00 ---
Even for live range analysis of the vars that must go into stack the block info
needs to be used, otherwise once address of a stack var escapes, you'd have to
assume it is live almost till the end of the function (at least live on any
function calls that might see it through global state, or global ptr
dereferences etc.). Using the block info, you can find out that:
{
char buf[10];
foo (buf);
bar ();
}
baz ();
in baz () call the buf var doesn't need to be live anymore. At least short
term I think it would be best just to walk the function to be expanded, look at
all gimple_block BLOCKs referenced and note which originally non-overlapping
BLOCKs are indeed still non-overlapping after the tree passes and don't
consider originally non-overlapping BLOCKs during stack slot sharing decisions
if they are overlapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-01 14:05 --- Yes, that's my thought too. Fixing the BLOCK_VARS when references to variables show up in a block where they weren't before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #5 from rguenther at suse dot de 2009-04-01 14:10 ---
Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink
breaks stack layout
On Wed, 1 Apr 2009, jakub at gcc dot gnu dot org wrote:
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 14:00 ---
Even for live range analysis of the vars that must go into stack the block
info
needs to be used, otherwise once address of a stack var escapes, you'd have to
assume it is live almost till the end of the function (at least live on any
function calls that might see it through global state, or global ptr
dereferences etc.). Using the block info, you can find out that:
{
char buf[10];
foo (buf);
bar ();
}
baz ();
in baz () call the buf var doesn't need to be live anymore. At least short
term I think it would be best just to walk the function to be expanded, look
at
all gimple_block BLOCKs referenced and note which originally non-overlapping
BLOCKs are indeed still non-overlapping after the tree passes and don't
consider originally non-overlapping BLOCKs during stack slot sharing decisions
if they are overlapping.
Note that once we use more precise alias information during RTL
optimizations (via alias exports patch) avoiding stack slot sharing
solely based on type-based conflicts will no longer be working.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-01 14:15 --- One would hope that with -fno-strict-aliasing we can still share the stack slots even with alias export patch, otherwise the kernel people are going to be extremely violent on us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #7 from rguenther at suse dot de 2009-04-01 14:29 --- Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout On Wed, 1 Apr 2009, jakub at gcc dot gnu dot org wrote: --- Comment #6 from jakub at gcc dot gnu dot org 2009-04-01 14:15 --- One would hope that with -fno-strict-aliasing we can still share the stack slots even with alias export patch, otherwise the kernel people are going to be extremely violent on us. I think it would be easier to fix scheduling to properly detect the must-conflicts by noting down the stack slot partition used in MEMs (and obviously if we end up having MEMs w/o an assigned parition make that conflict with any other - this can then be refined with PTA information from the alias export). The same is true for gcse-sm - any other RTL pass that may be a problem? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #8 from matz at gcc dot gnu dot org 2009-04-01 14:47 --- One other approach is to create new aliasing conflicts once we union two stack partitions. That would inhibit any invalid (after sharing) transformations by RTL transformations downstream (when they look at only such conflicts, i.e. TBAA). If they also look at other disambiguation possibilities then we indeed need to make the stack partition part of the IL and use it in the alias queries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-code Known to fail||4.4.0 Known to work||3.4.0 Summary|tree-ssa-sink breaks stack |[4.3/4.4/4.5 Regression] |layout |tree-ssa-sink breaks stack ||layout Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
