On Mon, May 11, 2015 at 6:25 PM, Alexander Monakov <amona...@ispras.ru> wrote: >> >>> LEGACY_REGS, which causes IRA not to consider it separately for register >> >>> allocation, even when it has lower cost than other classes. This patch >> >>> is >> >>> useful to fix code generation problem that appears with no-PLT PIC >> >>> tailcalls. >> >>> >> >>> Was there a specific reason for CLOBBERED_REGS class to be listed as >> >>> late as >> >>> it is? On 32-bit this class contains only EAX, ECX, EDX. >> >> >> >> Uros moved CLOBBERED_REGS late in >> >> https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00796.html >> >> which contains a rationale, too. >> >> >> >> I am adding Uros and Vladimir to CC just in case they missed the email :) >> >> Honza >> > >> > Uh, I don't remember that far, but from the context of the referred >> > patch, it looks like a "cleanup" of some sort. My atch matched 32bit >> > to 64bit, but could be also in the opposite way. Let's try the patch >> > and see what breaks. >> >> Ah, the reason was that 64bit targets have many more call-clobbered >> registers. So, I tried to position CLOBBERED_REGS according to the >> ascending number of registers in the register set. Maybe the most >> clean solution is to split the class to CLOBBERED_REGS_32 and >> CLOBBERED_REGS_64 classes and set the register constraint in >> constraints.md depending on TARGET_64BIT. > > Is there something to be gained by doing such a split? > > It seems to me that trying clobbered regs for allocation earlier that others > (thus, callee-saved) makes sense in general, at least for non-static > functions, > as callers in other TUs would have to save/restore those registers anyway.
OK, if the position of CLOBBERED_REGS doesn't affect other functionality (for 32, 64 and MS_ABI targets), then just move the definition to the better place. Please also add the comment explaining the rationale to prevent possible "cleanup" attempts in the future. Thanks, Uros.
