similar to: Registers for i128 data type not registered in X86

Hello, I m working towards backend. Here i need to define vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))],

Hi all, I've got a few new registers and I've extended the pointer size to be 128 bits. For allocas, that is done by adding another SelectionDAG after FrameIndex that extends it to 128 bits. That seems to work okay, except that the final representation throws in additional instructions. For example for a piece of code such as: int a; int* pointer = &a; it returns pushq %rbp

Hi all, I am currently working on AMDGPU inline assembly and encountered problem with naming clobber registers in asm constraints. It looks like by default LLVM tries to match register specified in constraint to register name of register definition in .td file but not to the AsmName for this register. For example if we have register definition: def MYReg0 : Register<"r0", 0>;

On 9/28/2016 7:30 PM, Quentin Colombet wrote: > Out of curiosity, could describe why this is useful to have such precision in the liveness tracking? RDF is meant to allow optimizations across the whole function. As a result, registers may change between basic blocks, and there is code to recalculate it. Accuracy is required to avoid unnecessary block live-ins. For example, calculate live-ins

Vivek, I apologize if you took my original email as a request for implementation, I meant to be asking what is already available, I think the answer to that is the ‘preserves_most’ and ‘preserves_all’ attributes, but I will also Use ‘regmask’ if those prove to be too sub-optimal. I am still interested in figuring out the necessary and sufficient conditions For LLC to do optimal IPRA