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.guent...@gmail.com> wrote:
> >
> > On Thu, Aug 29, 2019 at 9:54 AM Uros Bizjak <ubiz...@gmail.com> wrote:
> > >
> > > On Wed, Aug 28, 2019 at 5:12 PM Uros Bizjak <ubiz...@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 <ubiz...@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 <ubiz...@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. 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.
--
Alan Modra
Australia Development Lab, IBM
