Re: [PATCH] Value profile based optimizations, part 1

[Jan Hubicka <jh at suse dot cz>]

> Hello,
> 
> > > + /* Add code to measure histograms list of VALUES of length N_VALUES.  */
> > > + static void
> > > + instrument_values (unsigned n_values, struct histogram_value *values)
> > > + {
> > > +   rtx sequence;
> > > +   unsigned i, t;
> > > +   edge e;
> > > +  
> > > +   /* Emit code to generate the histograms before the insns.  */
> > > + 
> > > +   for (i = 0; i < n_values; i++)
> > > +     {
> > > +       e = split_block (BLOCK_FOR_INSN (values[i].insn),
> > > + 		       PREV_INSN (values[i].insn));
> > ..
> > > + 
> > > +       insert_insn_on_edge (sequence, e);
> > 
> > This looks unsafe to me.  The newly produced code can do nasty things 
> > (especially clobbering flags).  At the moment we do have number of
> > places in compiler that do assume that flags are dead at BB boundaries
> > and few other places in compiler that breaks this expectation.  I think
> > we should at least make it no worse.
> 
> you're of course right, but ...
> 
> > One way to do so without liveness information I can think of is to
> > emit just copy instruction at the specified place and put the complex
> > code to the exit edges from the basic block...
> 
> ... this really does not look as a good way to me.  It would force us to
> do not do the profiling in many cases from not really a good reason
> (when there is a computed goto at the end of block, or any non-flow
> edge). Also it would make the profiling code about twice as large.
> Note that I need liveness for one of vpt optimizations anyway,
> so we could use it.  Also I don't think that compiler performance is
> a problem here, as someone caring for it will hardly do a compilation
> with profile feedback and vpt enabled

I got to the same conclusion overnight (it was pretty late when I made
the email).  It would be easiest to simply build the liveness for
profiling and modify the hoisting code I have in cfganal.c (or
rtlanal.c?) to validate the sequence inclusion.  I am not sure what to
do when it fails to validate - Richard previously mentioned that we can
probably spill the hard registers that is tricky in some cases.  I would
be happy with the first solution that simply do validate and skip the
profiling when that fails.

We already have the problem with inserting the profiling code on s390
where flags may be live across basic block boundaries.  We can solve
this as side effect.
Honza
> 
> Zdenek