[PATCH] D66670: [AMDGPU] w/a for gfx908 mfma SrcC literal HW bug

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 23 12:10:54 PDT 2019


arsenm added a comment.

In D66670#1643385 <https://reviews.llvm.org/D66670#1643385>, @rampitec wrote:

> In D66670#1643378 <https://reviews.llvm.org/D66670#1643378>, @arsenm wrote:
>
> > In D66670#1643370 <https://reviews.llvm.org/D66670#1643370>, @rampitec wrote:
> >
> > > In D66670#1643363 <https://reviews.llvm.org/D66670#1643363>, @arsenm wrote:
> > >
> > > > Can we have different opcodes with a different source type?
> > >
> > >
> > > It will be a quite big change. What for?
> >
> >
> > Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally
>
>
> Anyway, you cannot have two opcodes with the same opcode without introducing a new encoding and a new decoder namespace. This bug will be fixed.


The encoding is the same, and a new decoder namespace shouldn't be an issue



================
Comment at: lib/Target/AMDGPU/SIInstrInfo.cpp:2873-2876
+    if (isMAI(MI) && ST.hasMFMAInlineLiteralBug() &&
+        OpNo ==(unsigned)AMDGPU::getNamedOperandIdx(MI.getOpcode(),
+                                                    AMDGPU::OpName::src2))
+      return false;
----------------
I would expect this to be in RI.opCanUseInlineConstant


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66670/new/

https://reviews.llvm.org/D66670





More information about the llvm-commits mailing list