On Sun, 10 May 2015, Uros Bizjak wrote: > On Sun, May 10, 2015 at 7:51 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > > On Sun, May 10, 2015 at 6:44 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >>> On 32-bit x86, register class CLOBBERED_REGS is a proper subset of > >>> 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. Alexander
