tree-SSA and indirect references.

tree-SSA and indirect references.

[Jan Hubicka]

Hi,
I re-tested my patch to elliminate addressof and noticed that there is
still noticeable regression on Gerald's testcase (but not on GCC
components test).  I modified addressof code to output variables that
were kept in registers and was looking back for the dumps.  There seems
to be common pattern of:

vara=(type *)&varb;
varc=*vara;

this is common for small aggregate casts that can stay in registers
after compiling.  What is our strategy to deal with this?  Is the
testcase gimple at first case and would be valid to turn it into
varc=(type)varb
for aggregates?  NOP expander seems to do right thing, but I am not sure
it is best idea.

Honza

Re: tree-SSA and indirect references.

[Richard Henderson]

On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote:
> vara=(type *)&varb;
> varc=*vara;
> 
> this is common for small aggregate casts that can stay in registers
> after compiling.  What is our strategy to deal with this?

I don't know.  I think it depends what the set of all these types are.


r~

Re: tree-SSA and indirect references.

[Jan Hubicka]

> On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote:
> > vara=(type *)&varb;
> > varc=*vara;
> > 
> > this is common for small aggregate casts that can stay in registers
> > after compiling.  What is our strategy to deal with this?
> 
> I don't know.  I think it depends what the set of all these types are.

In the case of Gerald's testcase these are different classes inherited
from each other.
They are iterators so the structures are small, I think containing just
one field.

Honza
> 
> 
> r~

Re: tree-SSA and indirect references.

[Richard Henderson]

On Tue, Jan 20, 2004 at 10:50:13AM +0100, Jan Hubicka wrote:
> > On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote:
> > > vara=(type *)&varb;
> > > varc=*vara;
> 
> In the case of Gerald's testcase these are different classes inherited
> from each other.

Would you please be concrete, draw the diagram and show the members?

My guess is that the best way to fix this is to change how the C++
front end implements inheritence.

At present, as you can see, the front end takes the address of the
base, casts, and then dereferences.  From the point of view of GIMPLE,
it would be much better to have this appear to be nested structures.
(The only exception will be for virtual bases, but I can see from the
above that that is not at issue for this test case.)

I have no idea how easy or difficult such a change might be.  Jason
or Mark, perhaps you could comment?


r~

Re: tree-SSA and indirect references.

[Jan Hubicka]

> On Tue, Jan 20, 2004 at 10:50:13AM +0100, Jan Hubicka wrote:
> > > On Tue, Jan 20, 2004 at 01:31:56AM +0100, Jan Hubicka wrote:
> > > > vara=(type *)&varb;
> > > > varc=*vara;
> > 
> > In the case of Gerald's testcase these are different classes inherited
> > from each other.
> 
> Would you please be concrete, draw the diagram and show the members?
> 
> My guess is that the best way to fix this is to change how the C++
> front end implements inheritence.
> 
> At present, as you can see, the front end takes the address of the
> base, casts, and then dereferences.  From the point of view of GIMPLE,
> it would be much better to have this appear to be nested structures.
> (The only exception will be for virtual bases, but I can see from the
> above that that is not at issue for this test case.)
> 
> I have no idea how easy or difficult such a change might be.  Jason
> or Mark, perhaps you could comment?

Actually the casts don't have to be very complex.  See for instance:
  <D175450>_4 = (short unsigned int * const *)&__first;
  T.14797_7 = *<D175450>_4;
  <D175454>_9 = (short unsigned int * const *)&__last;
  T.14799_12 = *<D175454>_9;
these two are operands of template:

void std::fill(_ForwardIter, _ForwardIter, const _Tp&) [with _ForwardIter = __gnu_cxx::__normal_iterator<short unsigned int*,
std::vector<short unsigned int, std::allocator<short unsigned int> > >, _Tp = short unsigned int] (__first, __last, __value)

so if I read it right, they shall differ only in constantness.

The other cass I saw were just same case of instantiation of template to
aggregate I think.

Honza
> 
> 
> r~

Re: tree-SSA and indirect references.

[Andrew Pinski]

On Jan 20, 2004, at 06:25, Jan Hubicka wrote:
> Actually the casts don't have to be very complex.  See for instance:
>   <D175450>_4 = (short unsigned int * const *)&__first;
>   T.14797_7 = *<D175450>_4;
>   <D175454>_9 = (short unsigned int * const *)&__last;
>   T.14799_12 = *<D175454>_9;
> these two are operands of template:
>
> void std::fill(_ForwardIter, _ForwardIter, const _Tp&) [with 
> _ForwardIter = __gnu_cxx::__normal_iterator<short unsigned int*,
> std::vector<short unsigned int, std::allocator<short unsigned int> > 
> >, _Tp = short unsigned int] (__first, __last, __value)
>
> so if I read it right, they shall differ only in constantness.

There is also PR 8781 which has the same exact problem and it is 
shorter.

Thanks,
Andrew Pinski

Re: tree-SSA and indirect references.

[Richard Henderson]

On Tue, Jan 20, 2004 at 08:57:24AM -0800, Andrew Pinski wrote:
> There is also PR 8781 which has the same exact problem and it is 
> shorter.

This is a different problem.  There are no casts involved.
After SRA and DCE, we have

  pred<D1926> = f;
  pred<D1933>.pred = &pred<D1926>;
  pred<D1940>.pred = &pred<D1933>;
  pred<D1947>.pred = &pred<D1940>;
  pred<D1954>.pred = &pred<D1947>;
  pred<D1961>.pred = &pred<D1954>;
  pred<D1968>.pred = &pred<D1961>;
  pred<D1975>.pred = &pred<D1968>;
  pred<D1982>.pred = &pred<D1975>;
  T.1<D2040>_54 = pred<D1933>.pred;
  T.2<D2041>_55 = *T.1<D2040>_54;
  T.3<D2042>_56 = T.2_55 ();

We don't get f propagated to T.2<D2041>_55 because (1) SRA doesn't
work on structures whose address is taken, and (2) we don't have
even *simplistic* propagation of field values for addressed structs.
Point the second is criminal.

The reason we don't delete 

  pred<D1940>.pred = &pred<D1933>;
  pred<D1947>.pred = &pred<D1940>;
  pred<D1954>.pred = &pred<D1947>;
  pred<D1961>.pred = &pred<D1954>;
  pred<D1968>.pred = &pred<D1961>;
  pred<D1975>.pred = &pred<D1968>;
  pred<D1982>.pred = &pred<D1975>;

is that we think that these objects have all have their address
taken, and thus might be referenced by the function call.  There
was one more iteration on the end that DCE removed, so in theory
repeated applications of DCE would clean this up.  However, I 
think the most dramatic improvement would be escape analysis.
None of the addresses in the chain is stored in globally accessible
memory, and thus the function call can't reference any of the
addresses, and thus they are all dead.


r~