similar to: [LLVMdev] Linear scan is going away after 3.0

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

Hi, 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 spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

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

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

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

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

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,

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

I just uploaded a blog post outlining the new register allocation algorithm in LLVM 3.0. http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html Please direct comments here. /jakob

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: > >> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> >> So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I >> would just follow the chains implied by the SibValueInfo Deps array? >> Basically, I want to find

Hi again Lang, I decided to try the approach you proposed to see whether it makes the assembly-code problem go away. Again, I tried a very simple register allocator (attached) that just calls vrm.assignVirt2Phys for every vreg in each function, mapping the vreg to the first preg in the register class. I tried two versions: one maps *every* vreg, and the other only maps those for which

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, Sorry - I had missed that you're using llvm-3.1, rather than the development branch. We encourage people to live on top-of-tree - it's well tested, easier for active developers to offer help with, and keeping up with incremental changes is often easier than porting between stable versions. It also sounds like you were building a Release version of LLVM. That will not have any

Hi, I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. I have tried two techniques, in the MachineFunction: 1. replace the MachineOperands in the users of the data with the new register/subregister index. This yields an assert failure

On Sep 19, 2012, at 4:02 PM, dag at cray.com wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: >> >>> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >>> >>> So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I >>> would just follow

I still get a coredump: 0 libLLVM-3.1.so 0x00007f0158a4e67f 1 libLLVM-3.1.so 0x00007f0158a500ca 2 libpthread.so.0 0x0000003a86c0f500 3 libLLVM-3.1.so 0x00007f01583c346c 4 libLLVM-3.1.so 0x00007f0158546349 llvm::FPPassManager::runOnFunction(llvm::Function&) + 521 5 libLLVM-3.1.so 0x00007f01585463e3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 6 libLLVM-3.1.so

On May 9, 2011, at 9:00 AM, Jonas Paulsson wrote: > Hi, > > I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. > > I have tried two techniques, in the MachineFunction: > > 1. replace the MachineOperands in the users

Hi, I would like to ask about PBQPs use of InlineSpiller. The code output when using PBQP gets a lot bigger compared to when using RegAllocGreedy. PBQP does not split the live intervals, and a lot more (often redundant) reload instructions are emitted as a result, it seems. I wonder why this is, and if there are any plans to improve on this point? /Jonas Paulsson -------------- next part