Don't mark convergent instructions as trivially rematerializable.

[jlebar]

Summary

No testcase, as all convergent MIs I'm aware of already have unmodeled
side-effects, which is sufficient.

[resistor]

My targets have convergent instructions that are rematerializable.

—Owen

[jlebar]

In D17429#356746, @resistor wrote:

My targets have convergent instructions that are rematerializable.

Interesting.

Are they *trivially* rematerializable? The documentation says a trivially-rematerializable instr must have no side-effects and must have the same effect wherever it's placed in the function. But if you can move the instruction wherever you want, then in particular you can add a control-flow dependency, which is what's specifically disallowed by convergence.

Maybe the documentation needs to be updated? I admit that I don't yet have a non-superficial understanding of what this is *used* for.

[resistor]

I have convergent instructions that are essentially register->register arithmetic operations. I don't have any great dependence on them being rematerialized, but I wanted to point out that it's not inconceivable.

[escha]

I think any GPU register SIMD operation counts as convergent and trivially rematerializable as long as it doesn't have side-effects (even if it probably wouldn't be particularly useful to in most cases).

example: a hypothetical f32reduce x, y that summed the values of 'y' for all the threads in a warp and saved the result in x.

It's convergent because you need to run it when all the relevant threads are enabled, but it doesn't have any side-effects, so if the same vreg representing 'y' is still available unmodified and control flow is the same, you could repeat it, I think.

[jlebar]

Thank you for your comments.

/ Return true if the instruction is trivially rematerializable, meaning it
/ has no side effects and requires no operands that aren't always available.
/ This means the only allowed uses are constants and unallocatable physical
/ registers so that the instructions result is independent of the place
/// in the function.
bool isTriviallyReMaterializable(const MachineInstr *MI

AIUI, this means our hypothetical f32reduce x, y is not trivially rematerializable, since its operands aren't always available.

I'm having difficulty imagining an op that has no side effects and requires no operands but which would nonetheless be unsafe to run while some threads are disabled (so is convergent). But would this putative instruction's result be independent of its place in the function? It seems not, since by assumption there is something different about running it while some threads are disabled vs when all threads are enabled.

Maybe I'm misunderstanding what it means when it says it requires no operands; I see LiveRangeEdit looking at the rematerializable instruction's inputs to check that they're available at the point to which it wants to move the instruction. But the issue of moving the instruction anywhere in a function -- not just elsewhere in a BB -- remains.

[jlebar]

Friendly ping. Would be good to have this figured out before we all lose state. :)

lib/CodeGen/TargetInstrInfo.cpp

isReallyTriviallyReMaterializableGeneric(const MachineInstr *MI,
   // simple, and a common case.
   int FrameIdx = 0;
   if (isLoadFromStackSlot(MI, FrameIdx) &&
       MF.getFrameInfo()->isImmutableObjectIndex(FrameIdx))
     return true;
 
   // Avoid instructions obviously unsafe for remat.
   if (MI->isNotDuplicable() || MI->mayStore() ||
-      MI->hasUnmodeledSideEffects())
+      MI->hasUnmodeledSideEffects() || MI->isConvergent())
     return false;
 
   // Don't remat inline asm. We have no idea how expensive it is
   // even if it's side effect free.
   if (MI->isInlineAsm())
     return false;
 
   // Avoid instructions which load from potentially varying memory.