Re: [RFC] New SRA and early interprocedural SRA

[Martin Jambor <mjambor at suse dot cz>]

Hi,

On Tue, Mar 24, 2009 at 07:07:31AM +0100, Jan Hubicka wrote:
> > 
> > The problem is that  in order to implement ipa_modify_actual_arguments
> > sanely  and not  to  pull whole  build_access_expr()  from ipa-sra  to
> > ipa-prop,  I need  to switch  to  using maybe_fold_offset_to_reference
> > first (and thus rewrite it at least a little bit).  I am mildly afraid
> > of this since I  learned that both you and Richi gave  up on it and it
> > will certainly take me at least  a week if not more.
> 
> What about making parm notes purely info of style "remove this parameter
> and put that to nonlocalized vars", "add here this new declaration" and
> keeping the separate array of substitutions (tree_map) saying how to
> modify the body?
> 
> I.e. bit lower form than what you have right now.  In that way logic on
> how to produce the subtitutions will still live in ipa-sra and I think
> it will be easy to lower what you have in parm notes now into such low
> parm notes.  It might however need two different notes that I didn't
> think of before :((

Having  two  kinds  of  notes   is  even  uglier  than  simply  making
build_access_expr  non-static and  puting it  into a  header  file.  I
believe I will  do just that so that  we can get on with  all sorts of
IPA infrastructure  (and I _really_  should start working  on function
specialization soon).   However, I will  probably try to  put "rewrite
fold_stmt" item to my TODO list (but I will discuss this internally at
suse  first) and  that shoud  also bring  about a  useful  function to
replace build_access_expr.

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
indirect   ref  expression   and  its   "value"   component_refs  (and
array_refs)  of  the indirect  ref?   That  sounds  weird... and  more
importantly, is there  any chance we are able to  encode such stuff in
dwarf?

> 
> I enabled IPA-SRA at -O2 on the branch now and it seems to show no
> regression in performance/code size/compilation time to justify -O3 only
> pass.  So I would like to keep it this way, all -O3 only code has
> tendency to rot.

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.

> 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.

Thanks,

Martin