142953 2015-03-22 18:28:41 -0700 DFG JIT code for BitAnd may be redundantly checking that the results is an int32. 2015-03-23 15:16:58 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 1 dtc-llvm webkit-unassigned fpizlo oldest_to_newest 1079189 0 dtc-llvm 2015-03-22 18:28:41 -0700 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? 1079209 1 dtc-llvm 2015-03-22 19:32:18 -0700 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 1079284 2 fpizlo 2015-03-23 08:28:20 -0700 Please try again in release mode. What you're seeing is assertions that we inject into the code, when you are in debug mode. 1079462 3 dtc-llvm 2015-03-23 15:16:58 -0700 (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.