On 2014-09-04 3:37 AM, Tom de Vries wrote:
On 03-09-14 18:58, Tom de Vries wrote:
I've build the patch and ran the fuse-caller-save tests, and I'm
currently
bootstrapping and reg-testing it on x86_64.
Vladimir,
This patch fixes a problem (found on s390) in one of the committed
fuse-caller-sa
On 03-09-14 18:58, Tom de Vries wrote:
I've build the patch and ran the fuse-caller-save tests, and I'm currently
bootstrapping and reg-testing it on x86_64.
Vladimir,
This patch fixes a problem (found on s390) in one of the committed
fuse-caller-save patches. s390 is the only user of the
I
On 03-09-14 20:12, Ulrich Weigand wrote:
Just for my curiosity, why is the second condition (after &&)
needed in this clause in the first place?
> if (ira_hard_reg_set_intersection_p (regno, mode,
>+ *crossed_calls_clobber_regs)
>+
Tom de Vries wrote:
> thanks for noticing this. I agree, this looks wrong, and is probably an
> oversight. [ It seems that s390 is the only target defining
> IRA_HARD_REGNO_ADD_COST_MULTIPLIER, so this problem didn't show up on any
> other
> target. ]
>
> I think attached patch fixes it.
>
>
On 01-09-14 18:41, Ulrich Weigand wrote:
Tom de Vries wrote:
* ira-costs.c (ira_tune_allocno_costs): Use
ALLOCNO_CROSSED_CALLS_CLOBBERED_REGS to adjust costs.
In debugging PR 53864 on s390x-linux, I ran into a weird change in behavior
that occurs when the following part of thi
Tom de Vries wrote:
> * ira-costs.c (ira_tune_allocno_costs): Use
> ALLOCNO_CROSSED_CALLS_CLOBBERED_REGS to adjust costs.
In debugging PR 53864 on s390x-linux, I ran into a weird change in behavior
that occurs when the following part of this patch was checked in:
> - if (ir
On 14-01-14 20:36, Vladimir Makarov wrote:
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.
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 look
On 13/01/14 16:16, Tom de Vries wrote:
> On 10-01-14 12:39, Richard Earnshaw wrote:
>> Consequently, you'll need to add a patch for AArch64 which has two
>> registers clobbered by PLT-based calls.
>>
Thanks for pointing that out. That's r16 and r17, right? I can propose the
>
On 10-01-14 12:39, Richard Earnshaw wrote:
>>Consequently, you'll need to add a patch for AArch64 which has two
>>registers clobbered by PLT-based calls.
>>
>
>Thanks for pointing that out. That's r16 and r17, right? I can propose the hook
>for AArch64, once we all agree on how the hook should l
On 10-01-14 12:39, Richard Earnshaw wrote:
On 09/01/14 20:42, Tom de Vries wrote:
On 09-01-14 15:41, Richard Earnshaw wrote:
On 30/03/13 16:10, Tom de Vries wrote:
On 29/03/13 13:54, Tom de Vries wrote:
I split the patch up into 10 patches, to facilitate further review:
...
0001-Add-command-l
On 09/01/14 20:42, Tom de Vries wrote:
> On 09-01-14 15:41, Richard Earnshaw wrote:
>> On 30/03/13 16:10, Tom de Vries wrote:
>>> On 29/03/13 13:54, Tom de Vries wrote:
I split the patch up into 10 patches, to facilitate further review:
...
0001-Add-command-line-option.patch
000
On 09-01-14 22:10, Andi Kleen wrote:
Tom de Vries writes:
Is this patch OK for stage1 (after proper retesting)?
Could you perhaps post the latest series first?
I don't think it made it to the mailing list.
Andi,
the current status is:
- toplevel of patch series:
http://gcc.gnu.org/ml/
Tom de Vries writes:
>
> Is this patch OK for stage1 (after proper retesting)?
Could you perhaps post the latest series first?
I don't think it made it to the mailing list.
-Andi
On 09-01-14 15:41, Richard Earnshaw wrote:
On 30/03/13 16:10, Tom de Vries wrote:
On 29/03/13 13:54, Tom de Vries wrote:
I split the patch up into 10 patches, to facilitate further review:
...
0001-Add-command-line-option.patch
0002-Add-new-reg-note-REG_CALL_DECL.patch
0003-Add-implicit-paramet
On 30/03/13 16:10, Tom de Vries wrote:
> On 29/03/13 13:54, Tom de Vries wrote:
>> I split the patch up into 10 patches, to facilitate further review:
>> ...
>> 0001-Add-command-line-option.patch
>> 0002-Add-new-reg-note-REG_CALL_DECL.patch
>> 0003-Add-implicit-parameter-to-find_all_hard_reg_sets.p
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-constrain
On 29/03/13 13:54, Tom de Vries wrote:
> I split the patch up into 10 patches, to facilitate further review:
> ...
> 0001-Add-command-line-option.patch
> 0002-Add-new-reg-note-REG_CALL_DECL.patch
> 0003-Add-implicit-parameter-to-find_all_hard_reg_sets.patch
> 0004-Add-TARGET_FN_OTHER_HARD_REG_USAGE
On 14/03/13 16:11, Vladimir Makarov wrote:
> On 03/14/2013 05:34 AM, Tom de Vries wrote:
>> On 13/02/13 23:35, Vladimir Makarov wrote:
>>
> Actually, I am done with it. In general, it is ok. Although I have
> some minors comments:
>
Vladimir,
Thanks for the review.
I split the patch up into
On 03/14/2013 05:34 AM, Tom de Vries wrote:
On 13/02/13 23:35, Vladimir Makarov wrote:
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.
Vlad
On 13/02/13 23:35, Vladimir Makarov wrote:
> On 13-02-07 2:11 PM, Tom de Vries wrote:
>> Vladimir,
>>
>> On 25/01/13 16:36, Vladimir Makarov wrote:
>>> On 01/25/2013 08:05 AM, Tom de Vries wrote:
Vladimir,
this patch adds analysis of register usage of functions for usage by IRA.
On 13-02-07 2:11 PM, Tom de Vries wrote:
Vladimir,
On 25/01/13 16:36, Vladimir Makarov wrote:
On 01/25/2013 08:05 AM, Tom de Vries wrote:
Vladimir,
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
Vladimir,
On 25/01/13 16:36, Vladimir Makarov wrote:
> On 01/25/2013 08:05 AM, Tom de Vries wrote:
>> Vladimir,
>>
>> 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
>
On 01/25/2013 08:05 AM, Tom de Vries wrote:
Vladimir,
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_nod
Vladimir,
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
25 matches
Mail list logo
