This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.
- From: Tom de Vries <Tom_deVries at mentor dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 14 Mar 2013 10:34:52 +0100
- Subject: Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.
- References: <510282FE.firstname.lastname@example.org> <5102A694.email@example.com> <5113FC6B.firstname.lastname@example.org> <511C1538.email@example.com>
On 13/02/13 23:35, Vladimir Makarov wrote:
> On 13-02-07 2:11 PM, Tom de Vries wrote:
>> On 25/01/13 16:36, Vladimir Makarov wrote:
>>> On 01/25/2013 08:05 AM, Tom de Vries wrote:
>>>> this patch adds analysis of register usage of functions for usage by IRA.
>>>> The patch:
>>>> - adds analysis in pass_final to track which hard registers are set or clobbered
>>>> by the function body, and stores that information in a struct cgraph_node.
>>>> - adds a target hook fn_other_hard_reg_usage to list hard registers that are
>>>> set or clobbered by a call to a function, but are not listed as such in the
>>>> function body, such as f.i. registers clobbered by veneers inserted by the
>>>> - adds a reg-note REG_CALL_DECL, to be able to easily link call_insns to their
>>>> corresponding declaration, even after the calls may have been split into an
>>>> insn (set register to function address) and a call_insn (call register), which
>>>> can happen for f.i. sh, and mips with -mabi-calls.
>>>> - uses the register analysis in IRA.
>>>> - adds an option -fuse-caller-save to control the optimization, on by default
>>>> at -Os and -O2 and higher.
>>>> Bootstrapped and reg-tested on x86_64, Ada inclusive. Build and reg-tested on
>>>> mips, arm, ppc and sh. No issues found. OK for stage1 trunk?
>>> Thanks for the patch. I'll look at it during the next week.
>> Did you get a chance to look at this?
> Sorry for the delay with the answer. I was and am quite busy with other
> more urgent things. I'll work on it when I have more free time. In any
> case, I'll do it before stage1 to have your patch ready.
do you have an ETA on this review?
>>> Right now I see that the code is based on reload which uses
>>> caller-saves.c. LRA does not use caller-saves.c at all. Right now we
>>> have LRA support only for x86/x86-64 but the next version will probably
>>> have a few more targets based on LRA. Fortunately, LRA modification
>>> will be pretty easy with all this machinery.
>> I see, thanks for noticing that. Btw I'm now working on a testsuite construct
>> dg-size-compare to be able to do
>> dg-size-compare "text" "-fuse-caller-save" "<" "-fno-use-caller-save"
>> which I could have used to create a generic testcase, which would have
>> demonstrated that the optimization didn't work for x86_64.
> 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
>> 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.