[Webkit-unassigned] [Bug 163548] Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=163548

--- Comment #2 from Filip Pizlo <fpizlo at apple.com> ---
This bug exists because our strategy to reason about interference at instruction boundaries doesn't capture the essence of what scratch registers are all about.  For any other kind of use, we know that the tmp holding the use will have to have been live across the previous instruction, so it will definitely interfere with the previous instruction's late defs and late clobbers.  So, we can safely conflate the execution of the previous instruction's late actions with the execution of this instruction's early actions.

Reasoning about interference only at instruction boundaries is also imprecise for register clobber sets - but only just. Imagine a pair of consecutive insts where the first has a dead def and the second has an early clobber. In fact, the dead def could use the same register as the early clobber, but we won't let that happen. Perhaps a better example is an inst with a late clobber followed by an inst with an early def. Clearly, the early def could use the same register as the previous instruction's late clobber, but we won't let it. That's actually a serious bug. It would mean that if you early define a floating point value and the thing before you is a CCall, you'll have a really bad time.

Fortunately, the only thing we have to do to ensure that things don't go wrong is to insert Nops to pad between instructions that have incompatible constraints.  Here are some Nop insertion rules that we could apply:

- Insert Nop before any instruction that claims early reg clobber and after any instruction that claims late reg clobber. I think that this would fix all known cases of this bug. This still means that the scratch registers of one inst could affect the colorability of early defs of the next inst, which is pretty weird.

- Insert Nop around scratch users. This wouldn't be enough, since it wouldn't fix the early def problem.

Maybe one way to look at this is that Scratch and EarlyDef are the problem children. Let's consider if this is really true by looking at the four main forms of arg kinds: early versus late crossed with use versus def.

Early Def: We know that this case is problematic, because it's exactly what happens in my current crash. It happens to be an early def triggered by Scratch.

Early Use: Uses cause liveness. Either the thing that is being used is defined by the previous instruction or it's live before the previous instruction - so either way, it interferes with all of the previous instruction's clobbers and defs.  No problem here.

Late Def: This case is also problematic. You could have a late def followed by something that early-clobbers all registers. In that case we'd want the def to use one of those registers and then insert spill code, but we can't do that if the def cannot get any regs at all.

Late Use: This could be a killing use. Imagine a late use followed by something that early-clobbers all registers.

Right now we don't have any clients that early-clobber all registers. But they may early-clobber some registers, and maybe this is enough to worry about.

Note that we can generalize this a bit further. A clobber is like a dead def. So the patterns of interference we have to worry about are:

Late Def or Late Clobber followed by Early Def or Early Clobber
Late Use followed by Early Def or Early Clobber.

Maybe what we should do is have a pre-pass for register allocators that inserts Nops to pad those bad cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161017/f0ddc6e1/attachment.html>