[LLVMdev] [RFC] Conditional RegClass membership

[David Chisnall]

On 13 Jul 2015, at 14:19, Artyom Skrobov <artyom.skrobov at arm.com> wrote:
> 
> James added, “Given these instructions are no longer unpredictable the rest of the compiler should know about them too, not just the MC layer, so this is even more of a hack,” – and he suggested instead converting every instruction that takes an rGPR operand into a multiclass of two instructions, one predicated on HasV8Ops, and the other on its inverse. This isn’t practical, however: ARMInstrThumb2.td specifies several hundred individual encodings, InstAliases and match patterns that use rGPR, and all these would need to be manually duplicated.
>  
> Right now, we’re trying to come up with a more sensible approach, and perhaps one that could be useful for other targets as well.
>  
> Any suggestions? And are there any other cases where the definition of a register class depends on target attributes?

The MIPS back end also includes a lot of hacks along this and basically follows James’ suggestion: almost every instruction is defined twice, once for 32-bit and once for 64-bit operations.

Having some mechanism in TableGen that would allow a register class used by instructions to be parameterised would simplify this a lot.  It would also simplify the C code if we could just ask for the definition of Mips::ADD (for example) for the current target, where currently we have a load of things like ABI.IsN64() ? Mips::AND64 : Mips::AND scattered about the place.

David