This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386]: Do not limit the cost of moves to/from XMM register to minimum 8.


On August 31, 2019 2:51:51 AM GMT+02:00, Alan Modra <amodra@gmail.com> wrote:
>On Fri, Aug 30, 2019 at 09:42:06AM +0200, Uros Bizjak wrote:
>> On Fri, Aug 30, 2019 at 9:22 AM Richard Biener
>> <richard.guenther@gmail.com> wrote:
>> >
>> > On Thu, Aug 29, 2019 at 9:54 AM Uros Bizjak <ubizjak@gmail.com>
>wrote:
>> > >
>> > > On Wed, Aug 28, 2019 at 5:12 PM Uros Bizjak <ubizjak@gmail.com>
>wrote:
>> > > >
>> > > > Attached patch improves costing for STV shifts and corrects
>reject
>> > > > condition for out of range shift count operands.
>> > > >
>> > > > 2019-08-28  Uroš Bizjak  <ubizjak@gmail.com>
>> > > >
>> > > >     * config/i386/i386-features.c
>> > > >     (general_scalar_chain::compute_convert_gain):
>> > > >     Correct cost for double-word shifts.
>> > > >     (general_scalar_to_vector_candidate_p): Reject count
>operands
>> > > >     greater or equal to mode bitsize.
>> > > >
>> > > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>> > > >
>> > > > Committed to mainline SVN.
>> > >
>> > > Ouch... I mixed up patches and actually committed the patch that
>> > > removes maximum from cost of sse<->int moves.
>> > >
>> > > I can leave the patch for a day, so we can see the effects of the
>cost
>> > > change, and if the patch creates problems, I'll revert it.
>> >
>> > Regresses gromacs and namd quite a bit on Haswell, also perl in
>SPEC 2000.
>> > I guess we should try understand why rather than reverting
>immediately
>> > (I'd leave it in at least another few days to get more testers pick
>up the
>> > rev.).
>> 
>> The correct patch is actually [1] (I have updated the subject):
>> 
>> 2019-08-28  Uroš Bizjak  <ubizjak@gmail.com>
>> 
>>     * config/i386/i386.c (ix86_register_move_cost): Do not
>>     limit the cost of moves to/from XMM register to minimum 8.
>> 
>> There is no technical reason to limit the costs to minimum 8 anymore,
>> and several targets (e.g skylake) also claim that moves between SSE
>> and general regs are as cheap as moves between general regs.

That's likely the issue since moves between regs in the same class can be usually dealt with in register renaming while between classes that is not generally possible. So I'd make those bigger cost. Otoh moves between same class regs are likely overcounted. 

 However,
>> these values were never benchmarked properly due to the mentioned
>> limitation and apparently cause some unwanted secondary effects
>> (lowering the clock).
>> 
>> I agree with your proposal to leave the change in the tree some more
>> time. At the end, we could raise the costs for all targets to 8 to
>> effectively revert to the previous state.
>> 
>> [1] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02009.html
>
>Those SPEC regressions sound similar to what I saw when trying to give
>proper costing to moves between general regs and vsx regs on Power9.
>rs6000.c:rs6000_ira_change_pseudo_allocno_class is the hack I used to
>work around bad register allocation decisions due to poor register
>pressure calculation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]