On 12/05/2013 07:47 PM, Tom de Vries wrote: > On 14-03-13 10:34, Tom de Vries wrote: >>> I thought about implementing your optimization for LRA by myself. >>> But it >>> >is ok if you decide to work on it. At least, I am not going to start >>> >this work for a month. >>>> >>I'm also currently looking at how to use the analysis in LRA. >>>> >>AFAIU, in lra-constraints.c we do a backward scan over the insns, >>>> and keep track >>>> >>of how many calls we've seen (calls_num), and mark insns with >>>> that number. Then >>>> >>when looking at a live-range segment consisting of a def or use >>>> insn a and a >>>> >>following use insn b, we can compare the number of calls seen for >>>> each insn, and >>>> >>if they're not equal there is at least one call between the 2 >>>> insns, and if the >>>> >>corresponding hard register is clobbered by calls, we spill after >>>> insn a and >>>> >>restore before insn b. >>>> >> >>>> >>That is too coarse-grained to use with our analysis, since we >>>> need to know which >>>> >>calls occur in between insn a and insn b, and more precisely >>>> which registers >>>> >>those calls clobbered. >>> > >>>> >>I wonder though if we can do something similar: we keep an array >>>> >>call_clobbers_num[FIRST_PSEUDO_REG], initialized at 0 when we >>>> start scanning. >>>> >>When encountering a call, we increase the call_clobbers_num >>>> entries for the hard >>>> >>registers clobbered by the call. >>>> >>When encountering a use, we set the call_clobbers_num field of >>>> the use to >>>> >>call_clobbers_num[reg_renumber[original_regno]]. >>>> >>And when looking at a live-range segment, we compare the >>>> clobbers_num field of >>>> >>insn a and insn b, and if it is not equal, the hard register was >>>> clobbered by at >>>> >>least one call between insn a and insn b. >>>> >>Would that work? WDYT? >>>> >> >>> >As I understand you looked at live-range splitting code in >>> >lra-constraints.c. To get necessary info you should look at >>> ira-lives.c. >> Unfortunately I haven't been able to find time to work further on the >> LRA part. >> So if you're still willing to pick up that part, that would be great. > > Vladimir, > > I gave this a try. The attached patch works for the included test-case > for x86_64. > > I've bootstrapped and reg-tested the patch (in combination with the > other patches from the series) on x86_64. > > OK for stage1? > Yes, it is ok for stage1. Thanks for not forgetting LRA and sorry for the delay with the answer (it is not a high priority patch for me right now).
I believe, this patch helps to improve code also because of better spilling into SSE regs. Spilling into SSE regs instead of memory has a rare probability right now as all SSE regs are call clobbered. Thanks again, Tom.
