Wilco Dijkstra writes:
> Hi Richard,
>
>> But even if the costs are too high, the patch seems to be overcompensating.
>> It doesn't make logical sense for an ADRP+LDR to be cheaper than an LDR.
>
> An LDR is not a replacement for ADRP+LDR, you need a store in addition the
> original ADRP+LDR. Basi
Hi Richard,
> But even if the costs are too high, the patch seems to be overcompensating.
> It doesn't make logical sense for an ADRP+LDR to be cheaper than an LDR.
An LDR is not a replacement for ADRP+LDR, you need a store in addition the
original ADRP+LDR. Basically a simple spill would be comp
Hi,
>> It's also said that chosen alternatives might be the reason that
>> rematerialization
>> is not choosen and alternatives are chosen based on reload heuristics, not
>> based
>> on actual costs.
>
> Thanks for the pointer. Yeah, it'd be interesting to know if this
> is the same issue, altho
Richard Biener writes:
> On Wed, May 11, 2022 at 2:23 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> Wilco Dijkstra writes:
>> > Hi Richard,
>> >
>> >> Yeah, I'm not disagreeing with any of that. It's just a question of
>> >> whether the problem should be fixed by artificially lowering the
On Wed, May 11, 2022 at 2:23 PM Richard Sandiford via Gcc-patches
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard,
> >
> >> Yeah, I'm not disagreeing with any of that. It's just a question of
> >> whether the problem should be fixed by artificially lowering the general
> >> rtx costs with one p
Wilco Dijkstra writes:
> Hi Richard,
>
>> Yeah, I'm not disagreeing with any of that. It's just a question of
>> whether the problem should be fixed by artificially lowering the general
>> rtx costs with one particular user (RA spill costs) in mind, or whether
>> it should be fixed by making the
Hi Richard,
> Yeah, I'm not disagreeing with any of that. It's just a question of
> whether the problem should be fixed by artificially lowering the general
> rtx costs with one particular user (RA spill costs) in mind, or whether
> it should be fixed by making the RA spill code take the factors
Wilco Dijkstra writes:
> Hi Richard,
>
>>> There isn't really a better way of doing this within the existing costing
>>> code.
>>
>> Yeah, I was wondering whether we could change something there.
>> ADRP+LDR is logically more expensive than a single LDR, especially
>> when optimising for size, so
Hi Richard,
>> There isn't really a better way of doing this within the existing costing
>> code.
>
> Yeah, I was wondering whether we could change something there.
> ADRP+LDR is logically more expensive than a single LDR, especially
> when optimising for size, so I think it's reasonable for the
Wilco Dijkstra via Gcc-patches writes:
> Hi Richard,
>
>> I'm not questioning the results, but I think we need to look in more
>> detail why rematerialisation requires such low costs. The point of
>> comparison should be against a spill and reload, so any constant
>> that is as cheap as a load sh
Hi Richard,
> I'm not questioning the results, but I think we need to look in more
> detail why rematerialisation requires such low costs. The point of
> comparison should be against a spill and reload, so any constant
> that is as cheap as a load should be rematerialised. If that isn't
> happen
Wilco Dijkstra writes:
> Improve rematerialization costs of addresses. The current costs are set too
> high
> which results in extra register pressure and spilling. Using lower costs
> means
> addresses will be rematerialized more often rather than being spilled or
> causing
> spills. This r
Improve rematerialization costs of addresses. The current costs are set too
high
which results in extra register pressure and spilling. Using lower costs means
addresses will be rematerialized more often rather than being spilled or causing
spills. This results in significant codesize reduction
Hi Richard,
> Can you fold in the rtx costs part of the original GOT relaxation patch?
Sure, see below for the updated version.
> I don't think there's enough information here for me to be able to review
> the patch though. I'll need to find testcases, look in detail at what
> the rtl passes ar
nd try to work out whether (and why) this is
a good way of fixing things.
I don't mind doing that, but I don't think I'll have time before stage 3.
Thanks,
Richard
>
>
> From: Wilco Dijkstra
> Sent: 02 June 2021 11:21
> To: GCC Patches
> Cc: Kyrylo Tkachov ; Richar
ping
From: Wilco Dijkstra
Sent: 02 June 2021 11:21
To: GCC Patches
Cc: Kyrylo Tkachov ; Richard Sandiford
Subject: [PATCH] AArch64: Improve address rematerialization costs
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get
ping
From: Wilco Dijkstra
Sent: 02 June 2021 11:21
To: GCC Patches
Cc: Kyrylo Tkachov ; Richard Sandiford
Subject: [PATCH] AArch64: Improve address rematerialization costs
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get
Hi Richard,
> No. It's never correct to completely wipe out the existing cost - you
> don't know the context where this is being used.
>
> The most you can do is not add any additional cost.
Remember that aarch64_rtx_costs starts like this:
/* By default, assume that everything has equivale
On 02/06/2021 11:21, Wilco Dijkstra via Gcc-patches wrote:
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get large gains for normal addressing too:
Improve rematerialization costs of addresses. The current costs are set too
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get large gains for normal addressing too:
Improve rematerialization costs of addresses. The current costs are set too
high
which results in extra register pressure and spilling. Usi
20 matches
Mail list logo
