[PATCH] D47434: AMDGPU: Turn D16 for MIMG instructions into a regular operand

[Nicolai Hähnle via Phabricator via llvm-commits]

nhaehnle added a comment.

In https://reviews.llvm.org/D47434#1116075, @arsenm wrote:

> In https://reviews.llvm.org/D47434#1114816, @nhaehnle wrote:
>
> > In https://reviews.llvm.org/D47434#1114811, @nhaehnle wrote:
> >
> > > In https://reviews.llvm.org/D47434#1114406, @arsenm wrote:
> > >
> > > > I was thinking of actually moving the opposite direction for these. For modeling partial register updates, I think having operands for all of these is unmanageable.  The problem is worse for ALU instructions with the zero high bit control bit. I think the same issues apply here. What is the behavior for the high bits if only 1 or 3 components are enabled?
> > >
> > >
> > > IIRC the high bits are preserved except when ECC is enabled.
> > >
> > > Okay, so modeling partial register updates. That would require us to add a $vdst_orig tied operand, right? Is there anything else, or any reason why we couldn't just do that unconditionally (but as an undef use), whether https://reviews.llvm.org/D16 or not?
> >
> >
> > Actually, can we have a VGPR32_LO/HI as the vdata register class for modeling the fact that the upper bits are preserved?
>
>
> I'm not sure. I've only looked at this a little bit before but it certainly needs experimentation. My guess is the tied operand will be necessary


Okay. Let's assume we don't get half-sized register classes and we do need the tied operand. The question at hand is whether https://reviews.llvm.org/D16 instructions need to be separate from non-D16 instructions. I would prefer them to be not separate, hence this patch. I think it should be possible to always have tied operands, but with undef uses in the non-D16 case. What do you think?


Repository:
  rL LLVM

https://reviews.llvm.org/D47434