D133866 added the llvm::isNeutralConstant helper to track neutral/passthrough constants
This patch updates foldSelectWithIdentityConstant to use the helper instead of maintaining its own opcode handling
Differential D134966
[DAG] Update foldSelectWithIdentityConstant to use llvm::isNeutralConstant RKSimon on Sep 30 2022, 7:41 AM. Authored by
Details D133866 added the llvm::isNeutralConstant helper to track neutral/passthrough constants This patch updates foldSelectWithIdentityConstant to use the helper instead of maintaining its own opcode handling
Diff Detail
Event TimelineComment Actions It looks to me equals to the old code.
Comment Actions as a headsup: I see this change causes failures in Halide https://github.com/halide/Halide/blob/main/test/correctness/div_round_to_zero.cpp on some architectures Comment Actions Any chance you can post the IR for that code? My first guess is that we've hoisted a div/rem, and that's illegal for this transform because those are not speculatable ops. Looks like this would only happen with a 512-bit vector on an AVX512VL target if I'm seeing the target hook restriction correctly. Comment Actions Looks like the Halide failure is a SIGFPE on an idiv instruction... we are doing idiv %r15b with edx=0xff, eax=0x8382ff80, r15=0xffffffff... i.e., we are dividing by -1. The result won't fit into 32 bits, so we fail. Comment Actions I'm guessing we had (sdiv %x, (select %c, %y, 1)) and turned it into (select %c, (sdiv %x, %y), %x). The original code may have been selecting a safe divisor. The new code is not. What happens if we remove SDIV and UDIV from isNeutralConstant? Comment Actions Update: confirmed that https://reviews.llvm.org/rG17dcbd8165479d5b2d7f827bfcb271b50ee03872 appears to fix the injection in Halide Comment Actions It seems this patch cause some performance regression on X86. I created D141782 to fix it. |
Are these two comments needed?