On Thu, 6 May 2021 at 18:51, Michael Matz <m...@suse.de> wrote:
>
> Hello,
>
> On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote:
>
> > Well, I was thinking of this test-case:
> >
> > int f(int cond1, int cond2, int cond3, int x, int y)
> > {
> > void f1();
> > void f2(int);
> > void f3();
> >
> > if (cond1)
> > f1 ();
> > else
> > {
> > if (cond2)
> > f2 (x + y);
> > else
> > f3 ();
> > }
> >
> > return x + y;
> > }
> > ...
> > And during second iteration, it hoists x + y into bb2. So we are
> > effectively hoisting x + y from bb5, bb7 into bb2, which doesn't seem to
> > benefit other two paths (bb2->bb3->bb7 and bb2->bb4->bb6->bb7) since
> > they don't contain x + y.
>
> But bb7 eventually does, so it also doesn't make those paths worse.
> That's the nature of partial redundancy elimination: it doesn't require
> benefits on all paths, only on one of them. That's in difference to full
> redundancy eliminaton.
>
> As with all hoistings it can increase register pressure. The counter
> measure to this is not to limit the hoisting (because that can have
> ripple down effects when some hoists don't happen anymore), but rather to
> tackle the register pressure problem somewhen later, in the register
> allocator (or some preparatory pass). But I'm not even sure if this is
> the reason you're wondering about how PRE hoists.
Hi Michael,
Yes, my concern was primarily w.r.t increased register pressure, and
was trying to think
of a "hack" that will disable hoisting in block if it could
potentially increase chances of spills,
offsetting it's benefit (altho the issue isn't limited to hoisting, I
was special casing it because hoisting
seems to regress a couple of benchmarks on arm and aarch64).
But yes, that doesn't look like the right approach.
Thanks,
Prathamesh
>
>
> Ciao,
> Michael.
