similar to: liveness tracking of a register class with a single sub-register

Hi. Is there anywhere on the LLVM code base a reusable bidirectional map similar to or better than http://www.boost.org/doc/libs/1_66_0/libs/bimap/doc/html/index.html? I need one and don't want to reinvent the wheel. Both keys are enums. Thanks, Dvir -------------- next part -------------- An HTML attachment was scrubbed... URL:

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

Hello, I've been trying to figure out how to reproduce the results of a single clang -O3 compilation to a binary with a multi-step process using opt. Specifically I have: clang -O3 foo.c -o foo.exe which I want to replicate with: clang -O0 -c -emit-llvm foo.c opt -O3 foo.bc -o foo_o.bc clang foo_o.bc -o foo.exe Any hints / suggestions on what additional flags I need to produce the same

Hi Susan, > You may find the PBQP allocator implementation useful as a reference > to what's involved in adding a new allocator to LLVM. It's located in > lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/CodeGen/ > PBQP directory. > Yes - as far as working allocators go PBQP is pretty simple. If you're just interested in LLVM API details you can focus on

Yes, I'm saying that the implicit-def operand that was added in this case ended up as #4, out of 6, when the operands list was reallocated in addOperand(). If addOperand was rewritten, I think it's best not to add my fix for ProcessUses(), as I wrote earlier. Jonas Subject: Re: [LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses() From: stoklund at 2pi.dk Date: Wed, 12 Oct 2011

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

Awesome, thanks! I'd like to have the last step (llc in your example) not perform additional optimization passes, such as O3, and simply use the O3 pass from opt in the previous line. Do you happen to know if I should use 'llc -O0 foo_o.bc -o foo.exe' instead to achieve this? On Thu, Jul 2, 2020 at 6:35 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Thu,

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

On Thursday 04 June 2009 19:03, Lang Hames wrote: > The new spilling framework inserts spill code in-place (during > register allocation) rather than deferring it using > VirtRegMap/VirtRegRewriter. The goal is to enable techniques like > iterative splitting to be implemented. It should also be a bit tidier > as it keeps more state in the MachineFunction, rather than in >

The new spilling framework inserts spill code in-place (during register allocation) rather than deferring it using VirtRegMap/VirtRegRewriter. The goal is to enable techniques like iterative splitting to be implemented. It should also be a bit tidier as it keeps more state in the MachineFunction, rather than in book-keeping structures like VirtRegMap. The work is in the very early stages though.

On May 3, 2011, at 3:24 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> On May 3, 2011, at 12:03 PM, David A. Greene wrote: > >>> Certainly. I would ask that we keep linearscan around, if possible, as >>> long as there are significant regressions like this. Our customers tend >>> to really, really care about

On Jan 14, 2013, at 1:39 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: >> >> On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >>> >>> My question is: is this something that was a part of the design? >> >> Yes, the register allocator

Hi Susan, I'm having trouble reproducing that error on my end, but I think the problem is probably that you're not using the VirtRegRewriter infrastructure. What your allocator needs to do is populate the virtual register mapping (VirtRegMap pass) with your allocation, rather than rewriting the registers directly through MachineRegisterInfo. Have your allocator require and preserve the