search for: getregforinlineasmconstraint

...ant to create inline assembly and add this register to clobbers list. Inline assembly should look something like this: i32 asm "nop", "~{r0}" () We used AsmName for register MYReg0 inside clobbers list. But this constraint fails to work because TargetLowering::getRegForInlineAsmConstraint() tries to match register definition name (“MYReg0”) not its AsmName (“r0”). So to make this work we should write this assembly: i32 asm "nop", "~{MYReg0}" () I believe that this behavior is not correct. It works because in most back-ends register definition n...

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

...uot;ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m ar.fpsr=$0", "r"( i64 2709527404217215 ) nounwind ret void } \end{ll} (See gcc/config/ia64/crtfastmath.c) In llvm::TargetLowering::getRegForInlineAsmConstraint(), the "r" constraint (i.e. TargetLowering::C_RegisterClass) isn't handled and the function returns <pair>(0, NULL). However, it is explicitly called for that constraint by llvm::SelectionDAGLowering::visitInlineAsm(): if (OpInfo.ConstraintType == TargetLowering::C_Regis...

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

...id @__ia64_set_fast_math() nounwind { > entry: > tail call void asm sideeffect "mov.m ar.fpsr=$0", "r"( i64 > 2709527404217215 ) nounwind > ret void > } > \end{ll} > > (See gcc/config/ia64/crtfastmath.c) > > In llvm::TargetLowering::getRegForInlineAsmConstraint(), the "r" > constraint > (i.e. TargetLowering::C_RegisterClass) isn't handled and the function > returns > <pair>(0, NULL). However, it is explicitly called for that > constraint by > llvm::SelectionDAGLowering::visitInlineAsm(): It's llvm::TargetLoweri...

.../src/llvm/test/CodeGen/Generic/ 2007-04-27-LargeMemObject.ll for PR1557 Failed with exit(1) at line 1 while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/ CodeGen/Generic/2007-04-27-LargeMemObject.ll | llc .ident "LLVM-ia64" .psr lsb .radix C .psr abi64 XXX: getRegForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegClassForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegClassForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegClassForInlineAsmConstraint XXX: getRegF...

...rcel Moolenaar wrote: > On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: >> The following IR is causing the assert: The issue here is that the IA64 backend doesn't have inline asm support yet. This should be pretty easy to add. Take a look at the X86 version: X86TargetLowering::getRegForInlineAsmConstraint it just maps "r" onto the GPR register class, itanium should do something similar. > Is it me or is the comment not really applicable to this particular > case? Right. The issue is that the target didn't return info about what it is, so the generic code is trying to guess...

Hi, I am seeing a case, in a private port, of an inline asm with indirect memory references being allocated invalid registers (i.e. registers that cannot be used on loads). For example, the inline asm constraint is correct: call void asm sideeffect "MOV $$r0, $0\0AMOV $$r0, $1\0A", "*m,*m,~{r0}"(i16* @a, i16* %b) #1, !srcloc !1 but then $0 and $1 are allocated to registers

I am hoping that someone can offer advice on a somewhat unusual issue that I am facing with the SDAG. Namely, I am trying to implement some custom operations that do very specific things on multiple registers at a time. The operations themselves will simply be intrinsics since there are no equivalent operations in IR/SDAG. However, handling the types seems rather tricky. One approach I tried is