<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - B3->Air lowering incorrectly copy-propagates over ZExt32's"
href="https://bugs.webkit.org/show_bug.cgi?id=152365#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - B3->Air lowering incorrectly copy-propagates over ZExt32's"
href="https://bugs.webkit.org/show_bug.cgi?id=152365">bug 152365</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>I should clarify that (4) does not require any copy propagation later. I think that this makes this approach the most scalable as well because it doesn't require a flow-sensitive analysis. Tmp's tend to have an SSA-like quality to them, so flow sensitivity buys relatively little.
We could even use this to convert more Move's into Move32's. Currently the instruction selector uses Move's for 32-bit values because Move32's are not coalescable. But they would become coalescable if we had an analysis that showed that the value is already zero-extended. There are two ways we could go about this:
i) Have the instruction selector emit Move32's for Int32's. Then coalesce Move32's that are proven to only see zero-extended values. This means that if we screw up our zero-extension analysis in Air (by being too conservative), we'll end up with Move32's that didn't get coalesced.
ii) Have the instruction selector still emit Move's for Int32's, but then have an analysis that converts the Move's into coalescable Move32's.
The second option, (ii), has the interesting property that we could convert Move's to Move32's using either backward or forward reasoning.
Forward reasoning: As I already described above.
Backward reasoning: Add the notion of Use32 and make UseDefZExt32 imply that the use is like Use32. If the destination of a Move is only used by Use32's then we can use Move32 instead.
Either way, the newly minted Move32 will be register-coalescable, in the sense that if the definitions of the Move32's source all use a register then the Move32 behaves like Move. From the standpoint of IRC, it means that if the source of the Move32 doesn't get spilled then it's coalescable, which in turn means that it's just coalescable no matter what.
Probably what this means is an analysis that IRC uses, which tells it which Move's and Move32's are really register-coalescable Move32's. IRC will either remove them, or turn them into Move's.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>