similar to: [LLVMdev] "ran out of registers during register allocation"

It seems like it might be a legitimate complaint from the register allocator. It's trying to get an accumulator (not a general purpose register) and the accumulator is 64 bit. It's using a part of the Mips backend that I have not worked in so I have to research this a bit. The multiply instruction is a pseudo multiply in the mips backend and it needs the accumulator which a special

On 12 May 2016 at 16:19, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The problem in PR24071 seemed to be that clang proceeded with compilation > even though the inline asm was not valid. I'm not sure that there is value > in trying to make the backend continue compiling code that most likely has > no meaning. I'm not 100% convinced that is the

In that case it tries to do something but fails. rkotler at ubuntu-rkotler:~/testmips16$ /home/rkotler/llvmw/install/bin/bugpoint casts.bc -llc-safe --safe-tool-args -target=mips-linux-gnu -mcpu=mips16 -mips16-constant-islands Read input file : 'casts.bc' *** All input ok Initializing execution environment: Found llc: /home/rkotler/llvmw/install/bin/llc Running the code

This is my first time using bugpoint. I'm getting the following error: /home/rkotler/llvmw/install/bin/bugpoint -run-llc casts.bc --tool-args -target mips-linux-gnu -mcpu=mips16 -mips16-constant-islands Read input file : 'casts.bc' *** All input ok Initializing execution environment: Found llc: /home/rkotler/llvmw/install/bin/llc Sorry, I can't automatically select a

----- Original Message ----- > From: "Reed Kotler" <rkotler at mips.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: LLVMdev at cs.uiuc.edu > Sent: Friday, November 22, 2013 11:18:53 PM > Subject: Re: bugpoint question > > In that case it tries to do something but fails. > > rkotler at ubuntu-rkotler:~/testmips16$ >

On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Sun, 03 Jun 2012 12:12:06 -0700 > Chris Lattner <clattner at apple.com> wrote: > > > > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > > > If I may add my two cents: > > > > > > I am planning to use LLVM as the backend for a compiler I am >

On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> On Sun, 03 Jun 2012 12:12:06 -0700 >> Chris Lattner <clattner at apple.com> wrote: >> >> > >> > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: >> >

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

I understand that but falling back makes the compilation slower. I'm wondering what could be done to remove this restriction about fast-isel not being able to handle non legal types. ________________________________________ From: Anton Korobeynikov [anton at korobeynikov.info] Sent: Sunday, August 31, 2014 12:55 AM To: Reed Kotler Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] lowering

On Mon, Jun 4, 2012 at 11:46 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >> On Sun, 03 Jun 2012 12:12:06 -0700 > >> Chris Lattner <clattner at apple.com>

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

Technically I don't need C/C++ code for it. I'm not really very good at writing LLVM assembly code by hand (but I should be - lol ). I'm working on fast-isel and I want to have executable tests for all of this and not just make check tests. It's easier for me to do that in C/C++ and then save the .ll and morph it into a make check test. I'm going through the fast-isel

----- Original Message ----- > From: "reed kotler" <rkotler at mips.com> > To: LLVMdev at cs.uiuc.edu > Sent: Friday, November 22, 2013 8:40:24 PM > Subject: [LLVMdev] bugpoint question > > This is my first time using bugpoint. I'm getting the following > error: > > /home/rkotler/llvmw/install/bin/bugpoint -run-llc casts.bc > --tool-args >

I tried out CommentFlag and it looks ideal for this purpose. The attached patch adds a FastISel flag and prints it in the AsmPrinter and the IR dump. You can then call MachineInstr::setAsmPrinterFlag(MachineInstr::FastISel) to set the flag. Some passes seem to be stripping the comment flags though. The one I noticed is the pseudo-instruction expansion pass: # *** IR Dump After Machine Copy

Fast-isel is not equipped in general to deal with non legal types. It would seem that an llvm assembler pass run after clang but before llvm could do the lowering though. Any thoughts? Reed

Thanks. So what about a fragment like this: (taken from fast-isel.ll in X86 ) define void @ptrtoint_i1(i8* %p, i1* %q) nounwind { %t = ptrtoint i8* %p to i1 store i1 %t, i1* %q ret void } TIA. On 09/29/2014 02:16 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 1:51 PM, reed kotler <rkotler at mips.com> wrote: >> >> What kind of C or C++ code will emit

Would adding a flag to MachineInstr::MIFlag do the trick? I'm thinking that fast isel could ensure that a flag (e.g. MIFlag::FastISel) is added to the instructions it creates, then the instruction printer could optionally emit a comment for instructions that have this flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

During ISel lowering, there are some stubs I realize that I need to emit during AsmPrinter. The question is: where to store that information? As a hack it could be stored in Subtarget. If there is a reasonable place to put it, it could be store in Module. Any ideas? It's just a list of functions that I need to generate stubs for. I know the possible elements of the list. It's a