[PATCH] D38175: [ARM] Make sure assembler rejects PC as an operand for VMOV.F16

Wed Nov 8 02:46:25 PST 2017

avieira added a comment.

Hi,

I started working on the first set of changes for this, taking the vmov instructions only. I added a new register class rGPR2 which behaves the way we want for these instructions. However, I ran into a failure in the CodeGen/ARM/fast-isel-align.ll test when it tried to generate the following:
%vreg6<def> = VMOVRS %vreg10, pred:14, pred:%noreg; GPR:%vreg6 SPR:%vreg10

This test has the flag -verify-machineinstrs and this check breaks saying it expected rGPR2 and not GPR. I also tried to use the existing GPRnopc instead, to make sure I wasn't just missing something somewhere, but I get the same error when verifying the machine instructions. The check is done based on the SuperClass, basically it checks that RC->hasSuperClassEq(DRC) and otherwise it errors out, where RC here is the GPRRegClass and DRC is either rGPR2RegClass (first attempt) or GPRnopcRegClass (second attempt).

After some playing around I found that adding the rGPR2RegClass as a register class in ARMISelLowering solved the issue with VMRS. However, I got a issue with VMOVSR, when the input register that is being used  is created as a rGPR or rGPRnopc.

The error reads something like:

  - Bad machine code: Illegal virtual register for instruction ***
- function:    unaligned_f32_load
- basic block: BB#0 entry (0x8313e98)
- instruction: %vreg9<def> = VMOVSR
- operand 1:   %vreg8

Expected a rGPR2 register, but got a GPRnopc register

The input register in question here is vreg8 from:
	%vreg8<def> = LDRi12 %vreg10, 2, pred:14, pred:%noreg; GPRnopc:%vreg8 rGPR:%vreg10
	%vreg9<def> = VMOVSR %vreg8, pred:14, pred:%noreg; SPR:%vreg9 GPRnopc:%vreg8

So I still have problems of register classes not being fully compatible. I was wondering whether anyone has any insight on how to tackle this or where I could look for more information on how all this fits together?

Thanks!

https://reviews.llvm.org/D38175