[llvm] [VPlan] Replace disjoint or with add instead of dropping disjoint. (PR #83821)
Florian Hahn via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 27 12:16:30 PDT 2024
================
@@ -1216,6 +1216,23 @@ void VPlanTransforms::dropPoisonGeneratingRecipes(
// load/store. If the underlying instruction has poison-generating flags,
// drop them directly.
if (auto *RecWithFlags = dyn_cast<VPRecipeWithIRFlags>(CurRec)) {
+ VPValue *A, *B;
+ using namespace llvm::VPlanPatternMatch;
+ // Dropping disjoint from an OR may yield incorrect results, as some
+ // analysis may have converted it to an Add implicitly (e.g. SCEV used
+ // for dependence analysis). Instead, replace it with an equivalent Add.
+ // This is possible as all users of the disjoint OR only access lanes
+ // where the operands are disjoint or poison otherwise.
----------------
fhahn wrote:
> Should this be taken care of by VPRecipeWithIRFlags::dropPoisonGeneratingFlags(), i.e., have it replace the opcode of a disjoint Or with Add?
Hmmm, it may work if there's no need to directly delete the old recipe, i.e. it will get cleaned up. Let me check.
> Should code based on such SCEV expressions be generated (expanded(?)) directly?
>
> (This case is reminiscent of dropping assumptions based on conditions subject to predication.)
At the moment, SCEV is only used for analysis of existing IR instructions in this case; switching use SCEV expansion for pointer expressions would probably introduce some other potential issues.
https://github.com/llvm/llvm-project/pull/83821
More information about the llvm-commits
mailing list