[PATCH] D63494: [AMDGPU] Fix for branch offset hardware workaround
Stanislav Mekhanoshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 20 07:30:00 PDT 2019
rampitec added inline comments.
================
Comment at: lib/Target/AMDGPU/SOPInstructions.td:1011-1018
+def S_CBRANCH_SCC0_64 : SOPP64 <
+ 0x00000004, (ins sopp_brtarget:$simm16),
+ "s_cbranch_scc0 $simm16"
+>;
+def S_CBRANCH_SCC1_64 : SOPP64 <
+ 0x00000005, (ins sopp_brtarget:$simm16),
+ "s_cbranch_scc1 $simm16"
----------------
rtaylor wrote:
> rtaylor wrote:
> > arsenm wrote:
> > > If the opcodes end up unavoidable, the class should be fixed to generate the branch and the dummy at the same time, rather than requiring repeating each definition with the opcode value
> > I can have a look at doing this.
> I don't think _Real is the best naming since there isn't a corresponding Pseudo but I had no clue what to call this multiclass so if anyone has a suggestion, I'm all ears.
_With_Relaxation?
================
Comment at: lib/Target/AMDGPU/SOPInstructions.td:974
+ def "" : SOPP<op, ins, asm, pattern>;
+ def _PAD_S_NOP : SOPP64<op, ins, asm, pattern>;
+}
----------------
rtaylor wrote:
> rampitec wrote:
> > Can yo use InstrMapping mapping here to avoid switches?
> Do you feel that this is worth it in this case? Seems overly complicated for a very specific use case but if it's the standard to go in this direction than ok.
You just get rid of one switch, so it is not that big deal now.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D63494/new/
https://reviews.llvm.org/D63494
More information about the llvm-commits
mailing list