Bug 288122 – [JSC][GreedyRegAlloc] Reconsider use of padInterference() by the greedy register allocator

• Component: JavaScriptCore
• Status: NEW

[Dan Hecht]

See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for why padInterference() is used by passes that perform liveness analysis (e.g. the graph coloring and linear scan register allocators).

The greedy register allocator does not suffer from the same issue since it models distinct late and early points between instructions: buildLiveRanges handles these late-def/uses followed by early-uses as distinct points, and so conflict analysis infers interference correctly.

However, the greedy register allocator does use padInterference for a related reason: when splitting around clobbers, it needs a way to model interference for the gapTmps, and there is no place to do this since there are no Points reserved for inserting these moves. Usually, it doesn't matter since it can make the interference work around correctly by fudging things, but in the case of late def/use followed by early use, it does need a distinct point. The Nop inserted by padIntereference provides that point.

An alternative would be to model four points per instruction, which would provide space for inserted instructions. That would probably be a cleaner solution and we should consider doing that. Then we wouldn't need to insert Nops. However, it's possible that subsequent compiler passes are also relying on these padIntereference inserted Nops (e.g. stack allocation maybe needs it for stack liveness).

[Radar WebKit Bug Importer]

<rdar://problem/145230375>