[PATCH] D18827: Rework/enhance stack coloring data flow analysis.

[Than McIntosh via llvm-commits]

Hi Wei,

You wrote:

*I try the following testcase using GCC and GCC still use 1024B stack*
*for it. So maybe GCC's implemention can still be improved?*


Yes, just so. What is happening here is that the code in GCC is looking at
"x + 2" in the final BB and conservatively assuming that it could write
memory. This means that conflicts are added between everything in the work
set, hence no overlap.

On the other hand, the GCC stuff runs at all optimization levels (even
-O0), so it makes sense that it is simple/conservative.

Than


On Mon, Apr 11, 2016 at 2:10 PM, Wei Mi <wmi at google.com> wrote:

> On Mon, Apr 11, 2016 at 10:38 AM, Than McIntosh <thanm at google.com> wrote:
> >
> > thanm added a comment.
> >
> > Wei wrote: //But isn't bar() could potentially change ar1 and ar2
> indirectly since ar1 and ar2 are escaped local arrays from current func?//
> >
> > GCC's implementation completely ignores "lifetime start" and instead
> adds a var X to the work set the first time it sees a reference to it. So
> on entry to BB1 it has not yet seen any references to "ar2", so when it
> processes "call bar(&ar1)" no edge is added. Ditto for processing BB2;
> live-in for the block is empty (since no explicit references in the entry
> block), so when it sees "call bar(&a2)" no edge is added. Both ar1 and ar1
> are part of the work set on entry to BB3, but BB3 has no instructions that
> could access memory.
> >
> Thanks.
>
> I try the following testcase using GCC and GCC still use 1024B stack
> for it. So maybe GCC's implemention can still be improved?
>
> extern void inita(int , int, const char *);
>
> int ifthen(int x, int i)
> {
>   int itar1[128];
>   int itar2[128];
>
>   if (x & 1) {
>     itar1[i] = 7;
>     inita(itar1[3], 128, "ifthen_itar1");
>   } else {
>     itar2[i] = 7;
>     inita(itar2[5], 128, "ifthen_itar2");
>   }
>   return x+2;
> }
>
> Thanks,
> Wei.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160411/d02d2849/attachment.html>