similar to: [LLVMdev] Register class proliferation

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

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

On Jun 21, 2011, at 10:20 AM, Jakob Stoklund Olesen wrote: > > 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,

On Jun 21, 2011, at 9:15 PM, Andrew Trick wrote: > We should make it clear that the performance problem is with register aliases, not classes. Yes, those are orthogonal issues. > Register aliasing is a serious problem with the current implementation. The postRA scheduler is *cubic* in the size of the alias list. You dramatically improved compile time with this simple fix: > >

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:

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-patch Size: 1915

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) return

On Jun 21, 2011, at 10:39 PM, Jakob Stoklund Olesen wrote: > The register allocators will check interference using atoms instead of aliases. That will be faster since every register has fewer atoms than aliases. It also scales well when adding support for register sequence constraints since new super-registers don't add any atoms. > > In the greedy and basic allocators, it means that

On Jun 22, 2011, at 5:01 PM, Andrew Trick wrote: > On Jun 21, 2011, at 10:39 PM, Jakob Stoklund Olesen wrote: >> The register allocators will check interference using atoms instead of aliases. That will be faster since every register has fewer atoms than aliases. It also scales well when adding support for register sequence constraints since new super-registers don't add any atoms.

[correction] On May 20, 2008, at 1:45 PM, Marcel Moolenaar wrote: > 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 =

On Wed, Jan 16, 2013 at 12:04:52PM -0500, Stephen Checkoway wrote: > > On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > > > I was wondering if someone with more familiarity with MC > > on X86 could consider looking into adding support for > > the hyphenated versions of the VIA Padlock instructions? > > > Take a look at

Hello, InstAlias does not allow tied operands (repeated operands) in the asm string to be matched. It seems this situation is explicitly prevented in AsmMatcherEmitter.cpp: if (!Hack) PrintFatalError(TheDef->getLoc(), "ERROR: matchable with tied operand '" + Tok + "' can never be matched!");

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 Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > I was wondering if someone with more familiarity with MC > on X86 could consider looking into adding support for > the hyphenated versions of the VIA Padlock instructions? Take a look at llvm/lib/Target/X86InstrSystem.td perhaps. -- Stephen Checkoway

I was wondering if someone with more familiarity with MC on X86 could consider looking into adding support for the hyphenated versions of the VIA Padlock instructions? If anyone is up for it there are details within these two bug reports.. http://www.llvm.org/bugs/show_bug.cgi?id=8556 http://www.llvm.org/bugs/show_bug.cgi?id=10266 -- This message has been scanned for viruses and dangerous

I am using some non-allocatable RegisterClasses to define lists of registers that are used for various non-allocation-related processing in the back end. For example, we have a post-allocation functional unit selection pass that is guided by the register assignment, which does things like 'myRegClass.contains(Reg)' to see if a register is in the set of registers accessible by a given unit.

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi, On Instructions you can use checkEarlyTargetMatchPredicate() to check that the operands are the same. There's an example of that in MipsAsmParser.cpp for DATI and DAHI. I can't think of a reason TableGen couldn't be made to allow this for InstAlias too. > On 15 Dec 2017, at 02:12, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > InstAlias

Hi, ABCRegister.td : def SGPR32 : RegisterClass<"ABC", [i32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; def SFGPR32 : RegisterClass<"ABC", [f32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; ===== Instruction selection ends: ... t8: i32 = ADDrr t37, t32

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