search for: getregclassforinlineasmconstraint

In file lib/Target/X86/X86ISelLowering.cpp Function X86TargetLowering::getRegClassForInlineAsmConstraint I think the second register must be X86::BL. else if (VT == MVT::i8) return make_vector<unsigned>(X86::AL, X86::DL, X86::CL, X86::DL, 0); Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

The attached patch implements a basic version of getRegClassForInlineAsmConstraint for ARM. Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061205/73bba6ef/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-...

The attached patch implements a basic version of getRegClassForInlineAsmConstraint for ARM. Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061205/4de106c5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-...

In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. What is the reason we don't like adding register classes? Is it still a valid reason? The new register allocators, fast and greedy, don't care at all. Their performance is independent of the number of register classes. Line...

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++

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

Hi, I found some suspicious code in X86TargetLowering::getRegClassForInlineAsmConstraint, but I don't know if it's a bug or my poor understanding of what the code does. This is the code in question: (lib/Target/X86/X86ISelLowering.cpp:5064) if (VT == MVT::i32) return make_vector<unsigned>(X86::EAX, X86::EDX, X86::ECX, X86::EBX, 0); else if (VT == MVT::i16) retu...

...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::TargetLowering::getRegClassForInlineAsmConstraint() that returns an empty vector and thus is the root case of the assert. It seems that llvm::TargetLowering::getRegForInlineAsmConstraint() is supposed to work on a single (physical) register. In GetRegistersForValue() is the following: 3817 // This is a reference to a register class that doe...

On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: > In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. > > What is the reason we don't like adding register classes? Is it still a valid reason? > As I recall, it's a performance issue, as some of the algorithms involved were non-linear and expensive. I think you'...

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote: > > On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: > >> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. >> >> What is the reason we don't like adding register classes? Is it still a valid reason? >> > > As I recall, it's a performance issue, as some of the algorithms involved were non-linear and expen...

...1557 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: getRegForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegClassF...

...; On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote: > >> >> On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: >> >>> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. >>> >>> What is the reason we don't like adding register classes? Is it still a valid reason? >>> >> >> As I recall, it's a performance issue, as some of the algorithms involved were...