search for: choosereg

...e.g. - InsnTimes handling. I have the feeling, this map can be eliminated completely. - use of the VRegReadTable. The vector of read occurences can be shortened every time, you processed the corresponding intruction. This makes it shorter and makes searches inside this vector faster, thus making chooseReg much faster. Probably also some other optimizations can be applied to the chooseReg function. - PhysRegsUseOrder - you remove some elements from the middle of this vector in removePhysReg. This is not a very efficient operation on the vectors, since it need to copy the tail of the vector. I think...

...ut it back. I'll get around to killing it again at some point. > - use of the VRegReadTable. The vector of read occurences can be > shortened every time, you processed the corresponding intruction. This > makes it shorter and makes searches inside this vector faster, thus > making chooseReg much faster. Probably also some other optimizations > can be applied to the chooseReg function. chooseReg is of course where most of the time is spent, but truth be told, 98% of the time my application spends in LLVM is *not* in the register allocator. Or I should say *was* not - a quick patch...

Hi everyone, Quick summary: LLVM now has a new register allocator particularly suitable for compiling (very) large, machine-generated functions. Longer story: I've recently been using LLVM in an application that involves JITing fairly large functions that have no control flow - they're just flat sequences of instructions, anywhere from 100 to 10000+ in size. (The control flow is