Re: [RFC] New SRA and early interprocedural SRA

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> However, I have  also realized that I don't really  know what I should
> store in nonlocalized variable  values in IPA-SRA for parameters which
> are  aggregates  passed by  reference.   Should  the  variable be  the

if parameter was int *old promoted to int new then I would store
ADDR_EXPR (new) as value.
Similarly for structure one can do ADDR_EXPR (CONSTRUCTOR (fields))...

Dwarf4 can encode the first as DW_OP_value (loc_list of new), the second
case is representable just in simple case of aggregate containing single
field (that is quite surprisingly common).

I have hack in the dwarf2out that in the case where we fail miserably to
represent value of pointer, I actually remove pointer from the
expression and produce initializer, so we would end up with
non-pointer argument containing the proper values as the original
argument points too in this case in unwind frame.

This is probably not best idea, but in C++ one sees a lot of instances
of this when method call was inliner, THIS pointer removed to references
to the object and object SRA-ed out, so I am thinking about discussing
this on DWARF ML.
GDB could probably do something funny like "I won't tell you value of
this pointer but try to dereference it and maybe I will tell you
something :)"
> 
> On  a  related note,  Richi  has noticed  that  compile  time of  wave
> increased drastically.  However,  it seems that it is  compilet at -O3
> anyway so I am not sure what  caused it.  I think it happened after my
> initial commit of the SRAs though.

Yep, I noticed it too.  Well, it might quite well be inlining
difference. If IPA-SRA does its job, then definitly we should see those.
> 
> > There is however problem with profile feedback that is now mismatching
> > so function bodies in profile geneerate run looks different from
> > function bodies at profile use run already during profile
> > generation.
> 
> I have managed to reproduce the problem but so far I have not examined
> it thoroughly and so have no clue what is going on.
> 
> > It means that you seem to do different decision when profiling or not
> > somehow.  This might be because your decision are dependent on something
> > instable such as value of memory pointer in hash?
> 
> Hmmm...  I can't think of anything.  Well, I'll have a look at the
> dumps.

Those issues tends to be fun :(
I should be online from tomorrow again, so fell free to ask.

Honza
> 
> Thanks,
> 
> Martin