search for: getregpressurelimit

Hello, why LLVM does not define physical register limits for MIPS by overriding the TargetRegisterInfo::getRegPressureLimit function the way it’s done for X86 in x86RegisterInfo.cpp and ARM. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120818/a8e4f353/attachment.html>

> I almost change all the instruction formats. It was a huge work. I am going > to compile and run it now. We have done the similar work[1] on this topic by gcc and we have start migrate our platform to LLVM. In my experience, you need to take care the follow part: * ARMBaseRegisterInfo::getRegPressureLimit * ARMBaseRegisterInfo::getRawAllocationOrder * CalleeSavedRegs * ARMFrameLowering::emitPrologue [1] Doubling the Number of Registers on ARM Processors http://aces.snu.ac.kr/interact-16/papers/interact-16-paper-1.pdf

I almost change all the instruction formats. It was a huge work. I am going to compile and run it now. Best Regards, A. Yazdanbakhsh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PhD. Student School of Electrical and Computer Engineering University of Wisconsin-Madison E-mail: yazdanbakhsh

...ARCv9). Could you please confirm these guesses? Are there any plans to eliminate these deficiencies? Another question I have is regarding register pressure estimates. I was wondering how to go about tracking the number of registers available on a target. The current schedulers (as of LLVM 2.8) use getRegPressureLimit(), but from what I can see the limits are rather rough - e.g. x86 gives a limit of 4 GP32 registers (presumably E[ABCD]X), even though, to the best of my knowledge, there are more generally available for allocation (e.g. SI, DI). It is also only taking the "top" register classes into acco...

...and CopyToReg instrs are used for the sole purpose of representing live-in and live-our regs? In other words, are there other uses for these? If yes, how do we identify the ones that represent live-in and live-out regs. (3) The current physical regsiter limits obtained using TargetRegisterInfo::getRegPressureLimit() seem to be too low (for example, 3 integer regs on x86 32-bit mode). Are these good limits to use in our case? If not, how can we get better limits? Thank you in advance! -Ghassan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/...

...unctional unit definitions at the moment that are used in scheduling. Patches would be welcome. > Another question I have is regarding register pressure estimates. I was wondering how to go about tracking the number of registers available on a target. The current schedulers (as of LLVM 2.8) use getRegPressureLimit(), but from what I can see the limits are rather rough - e.g. x86 gives a limit of 4 GP32 registers (presumably E[ABCD]X), even though, to the best of my knowledge, there are more generally available for allocation (e.g. SI, DI). It is also only taking the "top" register classes into acco...

...esent live-in and live-out regs. These DAG nodes are also used to copy to/from physical registers before and after calls. Virtual registers defined by PHI instructions will also appear as CopyFromReg operands. > (3) The current physical regsiter limits obtained using > TargetRegisterInfo::getRegPressureLimit() > seem to be too low (for example, 3 integer regs on x86 32-bit mode). Are these good limits to use in our case? If not, how can we get better limits? These limits are low exactly to make room for the global registers passing through a block without being used. The x86-32 architecture has so...