[llvm] r280412 - GlobalISel: add a G_PHI instruction to give phis a type.

Tim Northover via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 1 14:54:17 PDT 2016


Hi Quentin,

On 1 Sep 2016, at 14:39, Quentin Colombet <qcolombet at apple.com> wrote:
> The type must be consistent across the operands of the PHI and we could get it from the one of its operand, right?
> Though may not be super efficient and that’s not consistent.

It sounds like it could work, but is uglier. Extending the reasoning further you could say the same about any instruction with the same output types as input, but I don't think we want to go there. I think a world where every generic VReg is defined by a (generic) instruction specifying its type is the most sane way to handle things.

> We will have the same problem for COPY as well, or was the plan to use G_BITCAST for those?

I added G_TYPE to cover that yesterday. Still not entirely convinced about the name but I decided G_COPY would be too confusing because an actual COPY needs to be used for return values, and overloading G_BITCAST was a step too far (its operand may or may not have a type, which would be nasty).

> If the latter, I need to update the repairing code of RegBankSelect.

> Note: In the repairing code we replace copy around typed virtual registers, G_TYPE would work but seems a little weird in the sense that we said the RHS was untyped.

Yes, that seems like an argument in favour of creating a G_COPY which would leave us with the scheme:

  * G_COPY: SrcTy == DstTy
  * G_BITCAST: SrcTy != DstTy
  * G_TYPE: ∄ SrcTy

Which I think I'm OK with really, unless we can come up with a name that really does fit all three cases. I'm working on eliminating some uses of generic regs size at the moment, but after that I'll switch buildCopy to use a new G_COPY.

Tim.


More information about the llvm-commits mailing list