Re: [PATCH] experimental: code sinking

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Fri, Dec 04, 2020 at 10:15:30AM -0800, Linus Torvalds wrote:
> On Fri, Dec 4, 2020 at 9:45 AM Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> >
> > > There might be cases where instruction sinking makes sense even
> > > outside the "can we empty this bb entirely" issue. Not that I can
> > > think of any, but I wonder if this could be used to actually shrink
> > > liveness regions (if both the inputs to the sunk instruction are live
> > > _anyway_ at the target, then sinking the instruction should actually
> > > improve liveness in general, for example).
> >
> > I don't think I understand this. In the case of an UNOP, sinking it
> > increase the liveness and decrease the liveness of the output, so
> > it should not matter much.
> 
> Right. The UNOP case should be a no-op from a liveness perspective, but:
> 
> > In the case of an BINOP or select, sinking
> > it will decrease the liveness of the unique output but increase the
> > liveness of the inputs. So, it seems to me that sinking would
> > globally increase the liveness (contrary to moving up instructions).
> > Am I missing something?
> 
> No, moving a binop could actually *shrink* liveness under the right
> circumstances - namely when the sources of the binop are live
> regardless.

Hmm yes, indeed. I thought about that but I also implicitly thought
there was a dual effect for the output, but there isn't. And so the
'cost' is not the same before the 'last occurrence of other uses' than
after it. In short: "moving down is good but only when not too low,
unless it's an unop".

Anyway, the idea would be to do such moves only if they would effectively
empty and even then it's clear what is the exact advantage (other than
for imbalance). Also, moving it to the point where it is needed was very
easy. Moving it just past the CBR (or somewhere in the middle) will be more
complicated. I'll see.

-- Luc