[PATCH] D50633: [AMDGPU] Add new Mode Register pass

[Tim Corringham via Phabricator via llvm-commits]

timcorringham added inline comments.


================
Comment at: lib/Target/AMDGPU/SIModeRegister.cpp:160-180
+// Determine the Mode register setting required for this instruction.
+// Instructions which don't use the Mode register return a null Status.
+// Note this currently only deals with instructions that use the floating point
+// double precision setting.
+Status SIModeRegister::getInstructionMode(MachineInstr &MI,
+                                          const SIInstrInfo *TII) {
+  if (TII->usesFPDPRounding(MI)) {
----------------
arsenm wrote:
> arsenm wrote:
> > timcorringham wrote:
> > > arsenm wrote:
> > > > I'm not really comfortable inserting something semantically required at this point. Can you do this when the instructions are selected instead?
> > > The problem with doing it during instruction selection is that we end up with many more mode register writes than are strictly required. As the mode register is not modelled as a register there isn't any way to track the values without a pass to do it, I suppose it is similar to adding nops or waitcnts, which are also done by specific passes.
> > This is a semantic property and I think it really belongs in instruction selection. What is the problem with optimizing those out here? What actually changes?
> Or even earlier, a property of the emitted operation
An initial attempt at this functionality did insert necessary mode register writes at instruction selection, but that resulted in many more changes than were necessary as the state of the register isn't known at that point. In order to avoid some of  the changes all instructions that use the mode register would have to be updated to ensure the mode was appropriate - which was considered too invasive. A pass to remove unnecessary setregs would be possible, but would be very similar to this pass, but would still require changes to many instructions to insert the setregs, and would also provide extra overhead for all intervening passes.  There would have to be some dependence introduced between the mode register and the instructions that use it to ensure any rescheduling didn't break the code.
Overall we thought that this approach was the best compromise. It solves the immediate problem with minimal overhead, and can be extended in a staged manner fairly easily. 


Repository:
  rL LLVM

https://reviews.llvm.org/D50633