On Fri, Dec 4, 2020 at 8:34 AM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> A lot of the false 'context imbalance' warnings are caused by
> a potential jump-threading being blocked between 2 conditional
> branches on the same condition because the second CBR belong
> to a non-empty BB. Often the offending instructions can be moved
> to some other BB, sometimes even with some added advantages.
I hope you don't just use the context imbalance as a sign of this
being a good idea, because a lot of the context imbalances are likely
real and valid.
I do think moving the instruction to the (single) user sounds like a
good idea in some cases, but I'm a bit worried about doing it quite
this mindlessly. It can expand on liveness a lot - while the liveness
of the result of the sunk instruction shrinks, the liveness of the
sources to the sunk instruction can grow a lot.
That's obviously a non-issue for the use of sparse as an analysis tool
(and that's clearly the primary use), but I'd still like to think that
code generation might matter.
So I think this might be better with more heuristics. And explaining
them. Right now you have one heuristic: you only sink instructions
from bb's that end with a conditional branch. I'm not entirely sure
that I understand the reason for that heuristic, it smells a bit
arbitrary to me (I suspect it was the case you saw when looking at
examples).
On that note: would also be lovely to actually see examples of what
this results in - and not necessarily about just the context imbalance
again.
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).
Linus
