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?
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.