This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] conditional store elimination


Hi,

On Thu, 11 Oct 2007, Tehila Meyzels wrote:

> >I tweaked the patch a bit to only do the transformation by default if 
> >the target has conditional moves.
> 
> Sorry, but I didn't find where in the patch you are checking this. Could 
> you please enlighten?

In the hunk of toplev.c:

  if (flag_tree_cselim == AUTODETECT_VALUE)
#ifdef HAVE_conditional_move
    flag_tree_cselim = 1;
#else
    flag_tree_cselim = 0;
#endif

> There is another option, that will prevent the need of speculative load
> (and hence all the trapping/non trapping check):
> You can transform:
> 
>    if (cond)
>      *p = X;
> 
> ---------->
> 
>       q (points to a dummy stack slot)
>       if (cond)
>         q=p;
>       *q = X;
> 
> i.e., choose the address (that you store to) instead of the value.

Oh, that's an interesting idea, indeed.  Shouldn't be hard to do that if 
non-trappingness can't be proven.

> Few other points...
> What do you think about extending this to handle few conditional stores
> (and not only one)?

That's a logical extension and I think it would be nice to have.  The 
problem is, that the more stores you transform in this way, the more 
important the correct cost model is.  For instance it quickly becomes only 
worthwhile if we then really can if-convert the conditional block, which 
currently just so happens to be the case, as all these single-insn blocks 
are trivially convertible.  So if we want to the the former (and I agree 
that we want that), we should first tackle the latter.  And it's probable 
that this transformation then should rather be integrated in a real 
if-converter instead of being a separate pass doing this enabling 
transformation.

> What is your opinion that also conditional load hoisting will be included
> here?

Wasn't there disagreement if conditional load hoisting weren't better done 
by some other pass?  I don't really remember, and I also can't think of 
any other current pass which could do that.  Because in redundancy terms 
this transformation is a pessimization (if only one if arm contains a 
load), hence no current pass would do this transformation.  But a working 
cost model for hoisting cond loads would be even more important.

So if we would integrate these enabling transformations into the 
if-converter itself we prabably have a higher chance of succeeding.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]