https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125793

--- Comment #4 from Drea Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> (In reply to Drea Pinski from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > I'll mention tail merging here (which can only merge full equal blocks, 
> > > not
> > > tails of blocks).
> > 
> > I looked into that, there is a bug about changing tail merging over to use
> > ICF hashing and equals (PR 70032). Though there has been no progress on that
> > one for 10 years.
> 
> Yes.  I don't know how effective it still is, but I wouldn't mind dropping
> tail-merging completely.  

I was thinking about removing it once we all of the commoning sinking goes in.
I have to look into the numbers but I suspect tail-merging right now is mostly
just merging blocks containing abort; there was some empty bbs it was merging
before but I think those are now all handled by cfgcleanup. I should generate
the stats on that. So maybe it can be removed already.

> What I wanted to say is that we have an actual
> separate pass for such kind of transform (and an optimization flag), maybe
> we want to structure all this "commoning code by sinking" in a similar way. 

Understood.


> We have -fcode-hoisting as well, for the "commmoning code by hoisting" case.

Hoisting will be required if we do commonization via sinking. The problem is I
don't see how to use VN info to do sinking. I wonder if there is a way to do
hoisting as part of fre1 rather than doing it as part of pre. I have not looked
into what is needed to move it from pre to fre though. Because hoisting can
improve inlining choices in many (all?) cases.


> Though all the sinking commoning is guided by merge PHIs, thus "phiopt"
> and "if-conversion" technically matches as well.

Right sink is a good place to do the full commonalization for things like
switches and such.


So cs-elim I suspect is less important than before too. the main place where
that is used is for the triangle case and having the non-trapping information.
The question how important is the non-trapping information to have around.
Or is detecting:
```
*a = b;
if (c)
{
  ...; // No load/stores
  *a = d;
}
```
and transforming that enough now. (I need to get data on that too).

Reply via email to