RFC: [tree ssa] DSE extension

[Dale Johannesen]

On Apr 1, 2004, at 11:55 AM, Andrew Pinski wrote:
> On Apr 1, 2004, at 14:24, Dale Johannesen wrote:
>
>> In C++, it seems that an awful lot of unnecessary stack temp memory 
>> accesses are making it
>> through the optimizers.   For example (reduced from eon in SPEC):
>>
>> class YY { public:
>>   YY(const YY &v) { e[0] = v.e[0]; e[1] = v.e[1]; e[2] = v.e[2]; }
>>   double &y() { return e[1]; }
>>   double e[3];  };
>>
>> class XX { public:
>>   YY direction() const { return v; }
>>   YY v;  };
>>
>> int foo(XX& r) {
>>   if (r.direction().y() < 0.000001) return 0;
>>   return 1; }
>>
>> One possibility is to extend DSE to do better on stack temps, by 
>> temporarily inserting phony
>> stores in the exit block for all (nonvolatile) automatics (as 
>> suggested in Morgan 10.7.2).
>> That will at least get rid of the dead stores, although I don't think 
>> it will move the element(s) that
>> are used out of memory.  Am I missing some reason this is a bad idea? 
>>  What's a good way to
>> insert such stores?
>
> What really is needed to SRA with arrays in structs to fix this case 
> more than what my patch will do.

It's more than that, SRA will not consider anything that's marked 
Addressable.
The code I mentioned in tree-ssa-alias would have to be improved also.

> Also the C++ front-end needs to stop lower constructs like &r->v which 
> shows up in this testcase.
> I have a patch to help out the later which I will submit later today.

That may indeed help, thanks.

> Also here is a C example which produces worse code than the C++ 
> example as the stores are still
> there even on the RTL level:
>
> struct YY {
>   double e[3];  };
>
> static inline double *y(struct YY* this_1) { return &this_1->e[1]; }
>
> struct XX {
>   struct YY v;
>  };
>
> static inline struct YY direction (const struct  XX* this_1) { return 
> this_1->v;}
>
> int foo(const struct XX* r) {
>   struct YY t = direction(r);
>   if (*y(&t) < 0.000001) return 0;
>   return 1;
> }

Hmmm, without the copy constructor the copy remains as an aggregate 
copy through the tree
phases,  then is transformed to int copies in RTL.  Figuring out that 
those two int's correspond to
the one double that's loaded later is a more complex problem that I 
don't think any RTL phase is
trying to solve.  OTOH this is probably easier to handle in the tree 
phases than the original.