similar to: [LLVMdev] allocation_order_begin takes non-const reference for MachineFunction

Thanks, Reid. I've found that some overrides of allocation_order_begin() calls MachineFunction getInfo method. this method is not const. However, I think there could be default const implementation (const_cast of non-const method) and then allocation_order_begin() could be const. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Tony, It doesn't look right to me either. The "begin" and "end" methods which allocation_order_begin should return a const_iterator instead of an iterator. Those methods are "const". And, yes, the MachineFunction reference isn't even used so at the very least it could be const (if not removed). However, I'm not an expert in this area of the code.

Thanks, Ralph, this line worked well :) Here it is, my first patch to LLVM :) I've changed all allocation_order_begin() and allocation_order_end() methods to take const MachineFunction &MF as a parameter. I also added const version of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() functions to take const reference to MachineFunction. While doing this

Hi Chris, > On Wed, 16 Aug 2006, Anton Vayvod wrote: > > I'm willing :) I don't know how to do it. What's "to put together a > > patch"? :) > > In your local CVS tree, change the methods to be const, and adjust any > code that is neccesary for that to work. Once that is done, from the > top level, type 'cvs diff -u >& patch.txt'

I'm willing :) I don't know how to do it. What's "to put together a patch"? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060816/fb1f0b57/attachment.html>

Ok, I'm in process. Do I need to checkout the latest llvm source, first? I updated last right after the 1.8 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060816/fcf027c1/attachment-0001.html>

On Wed, 16 Aug 2006, Anton Vayvod wrote: > Thanks, Reid. > I've found that some overrides of allocation_order_begin() calls > MachineFunction getInfo method. this method is not const. However, I think > there could be default const implementation (const_cast of non-const method) > and then allocation_order_begin() could be const. That sounds reasonable to me. There should

On Wed, 16 Aug 2006, Anton Vayvod wrote: > I'm willing :) I don't know how to do it. > What's "to put together a patch"? :) In your local CVS tree, change the methods to be const, and adjust any code that is neccesary for that to work. Once that is done, from the top level, type 'cvs diff -u >& patch.txt' and attach patch.txt to an email. If

On Thu, 17 Aug 2006, Anton Vayvod wrote: > Thanks, Ralph, this line worked well :) > Here it is, my first patch to LLVM :) > I've changed all allocation_order_begin() and allocation_order_end() methods > to take const MachineFunction &MF as a parameter. I also added const version > of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() >

On Sep 3, 2010, at 10:46 AM, Jeff Kunkel wrote: > It's not too much of a problem then. I can make a DenseMap between the registers and my registers. It's just one more intermediate step for a lookup. > > I wish to mimic all the of the registers on the machine with my std::vector<RegisterInfo> RegisterIndexes; vector. Then when a register is used I can assign it easily. I

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code to change virtual registers to physical registers

On 8/7/07, David Greene <dag at cray.com> wrote: > > On Monday 06 August 2007 12:15, Anton Vayvod wrote: > > > Spill intervals must be precolored because they can't be spilled once > more. > > They are the shortest intervals precisely over each def/use of the > original > > interval. That is why they also have their weights set to #INF. > > Yes,

The target description .td files are allowed to change the default allocation order on a register class by overriding the allocation_order_begin() and allocation_order_end() methods on TargetRegisterClass. Previously, this was used all the time to filter out stack and frame pointers and other reserved registers. I was able to remove most of these custom allocation orders in the tree because the

It's not too much of a problem then. I can make a DenseMap between the registers and my registers. It's just one more intermediate step for a lookup. I wish to mimic all the of the registers on the machine with my std::vector<RegisterInfo> RegisterIndexes; vector. Then when a register is used I can assign it easily. I know about alias register and those are taken care of ever so

On Monday 06 August 2007 12:15, Anton Vayvod wrote: > Spill intervals must be precolored because they can't be spilled once more. > They are the shortest intervals precisely over each def/use of the original > interval. That is why they also have their weights set to #INF. Yes, that's true. But I wonder if we shouldn't be smarter about which register we pick to color it.

On Tuesday 07 August 2007 05:00, Anton Vayvod wrote: > > Yes, that's true. But I wonder if we shouldn't be smarter about which > > register we pick to color it. In Bill W's implementation, it was > > essentially random. What was your solution to this? > > I allocated spill intervals at the beginning of each iteration so all the > rest intervals (except of

install configuration built successfully too. llvm-gcc version is: gcc version 4.0.1 LLVM <Apple Computer, Inc. build 5400> how can I test it? I need to run make check in llvm/obj dir or in llvm-gcc/obj dir? Thanks On 8/4/06, Anton Vayvod <avayvod at gmail.com> wrote: > > Yes, I didn't install it myself. > > llvm-gcc4 has built successfully. > > Making

Hi all! I didn't manage to link my regalloc to lli (I added USEDLIBS to its makefile). Without it I can't run tests cause they need lli to be built. So how can I link createMyRegisterAllocator function to lli? Thanks. On 8/22/06, Anton Vayvod <avayvod at gmail.com> wrote: > > I managed to link my RegAlloc.a library to llc tool but can;t make the > same with lli tool.

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just

Hi! I'm developing a register allocator and need it to be available as an option for llc tool. I used to edit /lib/CodeGen/Passes.cpp for this aim but after yesterday's update these options are defined somewhere else and I can't find the place. Thanks for your help. Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL: