[PATCH 1/3] [ARM] Add bus_width_bits to tune_params

Kyrill Tkachov kyrylo.tkachov@foss.arm.com
Fri Sep 15 17:01:00 GMT 2017


On 15/09/17 16:38, Charles Baylis wrote:
> On 13 September 2017 at 10:02, Kyrill  Tkachov
> <kyrylo.tkachov@foss.arm.com> wrote:
>> Hi Charles,
>>
>> On 12/09/17 09:34, charles.baylis@linaro.org wrote:
>>> From: Charles Baylis <charles.baylis@linaro.org>
>>>
>>> Add bus widths. These use the approximation that v7 and later cores have
>>> 64bit data bus width, and earlier cores have 32 bit bus width, with the
>>> exception of v7m.
>>>
>> Given the way this field is used in patch 2 does it affect the addressing
>> mode generation
>> in the tests you added depending on the -mtune option given?
>> If so, we'll get testsuite failures when people test with particular default
>> CPU configurations.
> No, because the auto_inc_dec phase compares the cost of two different
> MEMs which differ only by addressing mode. The part of the calculation
> which depends on the bus_width is the same both times, so it is
> cancelled out.
>
>> Could you expand on the benefits we get from this extra bus_width
>> information?
>> I get that we increase the cost of memory accesses if the size of the mode
>> we load is larger than the
>> bus width, but it's not as if there is ever an alternative in this regard,
>> such as loading less memory,
>> so what pass can make different decisions thanks to this field?
> As far as this patch series is concerned, it doesn't matter. It is
> there to encapsulate the notion that a larger transfer results in
> rtx_costs() returning a larger cost, but I don't know of any part of
> the compiler which is sensitive to that difference. It's done this way
> because Ramana and Richard wanted it done that way
> (https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00652.html).

 From what I can tell Ramana and Richard preferred to encode this 
attribute as
a tuning struct property rather than an inline conditional based on 
arm_arch7.
I agree that if we want to use that information, it should be encoded 
this way.
What I'm not convinced about is whether we do want this parameter in the 
first place.

The cost tables already encode information about the costs of different 
sized loads/stores.
In patch 2, for example, you add the cost for extra_cost->ldst.load 
which is nominally just
the cost of a normal 32-bit ldr. But we also have costs for ldst.ldrd 
which is the 64-bit two-register load
which should reflect any extra cost due to a narrower bus in it. We also 
have costs for ldst.loadf (for 32-bit
VFP loads) and ldst.loadd (for 64-bit VFP D-register loads). So I think 
we should use those cost fields
depending on the mode class and size instead of using ldst.load 
unconditionally and adding a new bus_size parameter.

So I think the way forward is to drop this patch and modify patch 2/3 to 
use the extra_cost->ldst fields as described above.

Sorry for the back-and-forth. I think this is the best approach because 
it uses the existing fields more naturally and
doesn't add new parameters that partly duplicate the information encoded 
in the existing fields.
Ramana, Richard: if you prefer the bus_width approach I won't block it, 
but could you clarify your preference?
If we do end up adding the bus_width parameter then this patch and patch 
2/3 look ok.
Thanks,
Kyrill

P.S. I'm going on a 4-week holiday from today, so I won't be able to do 
any further review in that timeframe.
As I said, if we go with the bus_size approach then these patches are 
ok. If we go with my suggestion, this would
be dropped and patch 2 would be extended to select the appropriate 
extra_cost->ldst field depending on mode.



More information about the Gcc-patches mailing list