search for: regallocfast

Any ideas? Instruction uses an alias of an allocated register UNREACHABLE executed at RegAllocFast.cpp:358! 0 clang 0x0000000101309bc2 PrintStackTrace(void*) + 34 1 clang 0x000000010130a863 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff8056935a _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2141809856 4 clang 0x00000001012dd96d...

On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: > I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations...

...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: llvm/lib/CodeGen/RegisterScavenging.cpp:196: void llvm::RegScavenger::forward(): Assertion `SubUsed && "Using an undefined register!"' failed. In r103685 ("More asserts around physreg uses") the error changed...

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 discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations...

On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: > > On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: > >> I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations...

On Jul 11, 2011, at 3:06 PM, Eli Friedman wrote: > On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: >> >> This seems odd. I'd think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block. > > I'm

On Jul 11, 2011, at 3:41 PM, Dan Gohman wrote: > On Jul 11, 2011, at 3:06 PM, Eli Friedman wrote: > >> On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: >>> >>> On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: >>> >>> This seems odd. I'd think that fast-isel should be able to materialize the constants when

On Jul 11, 2011, at 3:43 PM, Eric Christopher wrote: > > On Jul 11, 2011, at 3:41 PM, Dan Gohman wrote: > >> On Jul 11, 2011, at 3:06 PM, Eli Friedman wrote: >> >>> On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: >>>> >>>> On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: >>>>

...in __assert_fail () from /lib/libc.so.6 #3 0x0081b60c in bundle_iterator (this=0x7fdff580, mi=0x241393c) at /scratch/tmp/octeon/llvm-test/source/include/llvm/CodeGen/MachineBasicBlock.h:153 #4 0x014e6f78 in spillAll (this=0x240d200, MI=0x241393c) at /scratch/tmp/octeon/llvm-test/source/lib/CodeGen/RegAllocFast.cpp:324 #5 0x014ed6f4 in AllocateBasicBlock (this=0x240d200) at /scratch/tmp/octeon/llvm-test/source/lib/CodeGen/RegAllocFast.cpp:1101 1. spillAll(MBB->getFirstTerminator()) at RegAllocFast.cpp:1101 is invoked. getFirstTerminator returns an end iterator here and is converted to MachineInstr* w...

...ort any bugs you find. >> > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Thanks for testing it! [...] > And with latest it is now: > Instruction uses an allocated register > UNREACHABLE executed > at /home/kraiskil/llvm/svn-clean/llvm/lib/CodeGen/RegAllocFast.cpp:302! This is RegAllocFast's way of saying "Oops, I clobbered the return value from your CALL. Didn't think you would need it." The problem is this code: BB#0: derived from LLVM BB %0 BRASL <ga:@extFunc>, %R0<imp-def>, %R1<imp-def>, %R3<imp-def>, %R0...

I'm getting this error in RegAllocFast.cpp in compiling one source file in test-suite as the result of a new Mips fast-isel patch I was testing. It apparently just generates bad code and continues? // Nothing we can do. Report an error and keep going with a bad allocation. if (MI->isInlineAsm()) MI->emitError("...

...cial register and there is only one and it has special properties. This may normally be getting sorted out by some code which is not present during fast-isel. On 01/02/2015 02:41 PM, Philip Reames wrote: > > On 01/02/2015 02:24 PM, reed kotler wrote: >> I'm getting this error in RegAllocFast.cpp in compiling one source >> file in test-suite as the result of a new Mips fast-isel patch >> I was testing. >> >> It apparently just generates bad code and continues? >> >> // Nothing we can do. Report an error and keep going with a bad >> allocatio...

I have noticed quite a few changes regarding register allocation. I am wondering will there be support for radically different data structures other than the LiveIntervals, Virtual Register Map, etc? I have build a custom data structure which has it's own intermediate representation like live-intervals, but much more conducive for my allocation algorithm. I do not know if LiveIntervals can

...ich has it's own intermediate > representation like live-intervals, but much more conducive for my > allocation algorithm. I do not know if LiveIntervals can accurately > describe my data structure, and it would be a huge hack to enforce the > live interval framework. So don't. RegAllocFast isn't using LiveIntervals either. It is entirely optional. /jakob

Hi, I wanted to write a new register allocation algorithm. I wrote it the same way RegAllocFast has been written and registered it. I added it to ForceCodegenLinking struct as well. But after build, it is not listed in llc --help. I tried to change the registered name of greedy algorithm to something else and that doesnt seem to be reflecting in llc help either. Am i supposed to build l...

...f Matthias Braun <mbraun at apple.com> Sent: Saturday, September 9, 2017 2:06 AM To: jin chuan see Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Live Register Spilling This would be a lot easier to discuss having a concrete example, llc invocations etc. It sounds like you are using RegAllocFast, have you tried using the optimized register allocators (= make sure you don't have the optnone attribute on your function and are not passing -O0 to the tools). - Matthias On Sep 8, 2017, at 12:10 AM, jin chuan see via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm....

Hi All, I faced some problems while using the BuildMI(). Currently, i am trying to replace specific MI with a series of new MI. I wrote a routine under the processFunctionAfterISel() to detect the targeted MI and replace it accordingly. After using BuildMI() to perform my replacement, i realize there are unnecessary spilling and reloading of registers in the assembly generated. By checking

...for completeness. not contained in 1pass O3 (count=18) -aa-scalar-evolution -always-inline -callsite-splitting -inject-tli-mappings -ipsccp -jump-threading-correlated-propagation -livedebugvalues -loops-loop-simplify -memdep-lazy-branch-prob -openmpopt -opt-remark-emitter-instcombine -regallocfast -speculative-execution -stackmap-liveness -tbaa-scoped-noalias -vector-combine -verify -write-bitcode not contained in multi O3 (count=67) -attributor -block-freq-loop-simplify -branch-folder -break-false-deps -callsite-splitting-ipsccp -codegenprepare -consthoist -dead-mi-eliminatio...

...s >> >> -ipsccp >> >> -jump-threading-correlated-propagation >> >> -livedebugvalues >> >> -loops-loop-simplify >> >> -memdep-lazy-branch-prob >> >> -openmpopt >> >> -opt-remark-emitter-instcombine >> >> -regallocfast >> >> -speculative-execution >> >> -stackmap-liveness >> >> -tbaa-scoped-noalias >> >> -vector-combine >> >> -verify >> >> -write-bitcode >> >> not contained in multi O3 (count=67) >> >> -attributor >...