Bug 122688 – FTL OSR exit should perform zero extension on values smaller than 64-bit

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Filip Pizlo]

In the DFG we usually make the simplistic assumption that a 32-bit value in a 64-bit register will have zeros on the high bits.  In the few cases where the high bits are non-zero, the DFG sort of tells us this explicitly.

But when working with llvm.webkit.stackmap, it doesn't work that way.  Consider we might emit LLVM IR like:

 %2 = trunc i64 %1 to i32
 stuff %2
 call @llvm.webkit.stackmap(...., %2)

LLVM may never actually emit a truncation instruction of any kind.  And that's great - in many cases it won't be needed, like if %2 is a 32-bit op that ignores the high bits anyway.  Hence LLVM may tell us that %2 is in the register that still had the value from before truncation, and that register may have garbage in the high bits.

This means that on our end, if we want a 32-bit value and we want that value to be zero-extended, we should zero-extend it ourselves.  This is pretty easy and should be cheap, so we should just do it and not make it a requirement that LLVM does it on its end.

[Filip Pizlo]

Created attachment 214049 [details]
the patch

[Filip Pizlo]

Created attachment 214050 [details]
the patch

Fix changelog.

[Nadav Rotem]

Do you need to do anything about Int52s ?

[Filip Pizlo]

(In reply to comment #3)
> Do you need to do anything about Int52s ?

In LLVM IR, int52's are always expressed as i64's.  So it would be weird if we had to do anything.

For example if we have an int52 end up in a stackmap it will be like "stackmap(i64 %myInt52)".  Sure, %myInt52 will either have 12 low zero bits or 12 high sign extension bits, but since I'm claiming to be passing an i64, LLVM ought to preserve those since anything else would probably be a violation of IR rules.

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/157382