| Summary: | DFG JIT code for BitAnd may be redundantly checking that the results is an int32. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | dougc <dtc-llvm> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | fpizlo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Might be seeing the same on the result of an int32 typed array load. For example:
473:<!2:loc10> GetByVal(KnownCell:@450, Int32:@470, @521, JS|MustGen|PureInt|UseAsInt, Int32, Int32ArrayOriginalNonArrayInBoundsAsIs, R:TypedArrayProperties,MiscFields, bc#803) predicting Int32
0x7f68c8000e45: mov $0x7f690806fe30, %rcx
0x7f68c8000e4f: cmp $0x400000, %edx
0x7f68c8000e55: jae 0x7f68c80012cd
0x7f68c8000e5b: mov (%rax,%rdx,4), %ebx
0x7f68c8000e5e: mov $0xffffffff, %r11 ; redundant int32 assertion?
0x7f68c8000e68: cmp %r11, %rbx
0x7f68c8000e6b: jbe 0x7f68c8000e78
0x7f68c8000e71: mov $0x32, %r11d
0x7f68c8000e77: int3
Please try again in release mode. What you're seeing is assertions that we inject into the code, when you are in debug mode. (In reply to comment #2) > Please try again in release mode. What you're seeing is assertions that we > inject into the code, when you are in debug mode. Yes, these are not emitted in Release code, sorry for the noise. |
For BitAnd with a constant int32 argument the result is known to be an int32. However function 'int32Result()' emits the int32 assertion 'jitAssertIsInt32(reg)' that looks redundant. For example: 87:< 3:loc13> BitAnd(Int32:@76, Int32:@84, Int32|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, Int32, bc#117) 0x7f2d12000716: mov %r9, %r10 0x7f2d12000719: and $0x7fc, %r10d 0x7f2d12000720: mov $0xffffffff, %r11 ; redundant int32 assertion? 0x7f2d1200072a: cmp %r11, %r10 0x7f2d1200072d: jbe 0x7f2d1200073a 0x7f2d12000733: mov $0x32, %r11d 0x7f2d12000739: int3 There seems to be potential to optimize away this assertion, at least for the case of BitAnd with a constant int32 argument. Might the arguments to the bitwise operations always be int32 values when emitting this code? If so then might the result always be int32 for them?