This is an archive of the discontinued LLVM Phabricator instance.

[DAG] Update foldSelectWithIdentityConstant to use llvm::isNeutralConstant
ClosedPublic

Authored by RKSimon on Sep 30 2022, 7:41 AM.

Details

Summary

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 Timeline

RKSimon created this revision.Sep 30 2022, 7:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2022, 7:41 AM
RKSimon requested review of this revision.Sep 30 2022, 7:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2022, 7:41 AM
pengfei accepted this revision.Sep 30 2022, 9:07 AM

It looks to me equals to the old code.

llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
10753–10754

Are these two comments needed?

This revision is now accepted and ready to land.Sep 30 2022, 9:07 AM
RKSimon added inline comments.Sep 30 2022, 9:14 AM
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
10753–10754

The NSZ TODO can certainly go - I haven't come across any real world cases where target opcodes would be useful yet, but theoretically they could be, so I might keep that one.

The getBinOpIdentity TODO should probably be a NOTE instead

This revision was landed with ongoing or failed builds.Sep 30 2022, 9:47 AM
This revision was automatically updated to reflect the committed changes.

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

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

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.

srj added a subscriber: srj.Oct 4 2022, 1:55 PM

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.

craig.topper added a comment.EditedOct 4 2022, 2:02 PM

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.

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?

srj added a comment.Oct 4 2022, 2:19 PM

Update: confirmed that https://reviews.llvm.org/rG17dcbd8165479d5b2d7f827bfcb271b50ee03872 appears to fix the injection in Halide

It seems this patch cause some performance regression on X86. I created D141782 to fix it.