> On 11/06/2017 12:11 AM, Uros Bizjak wrote:
> > On Mon, Nov 6, 2017 at 12:19 AM, Peryt, Sebastian
> > <sebastian.pe...@intel.com> wrote:
> >>> On Sun, Nov 5, 2017 at 12:14 PM, Peryt, Sebastian 
> >>> <sebastian.pe...@intel.com>
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> After r253934 gcc.target/i386/pr71321.c started to fail due to the wrong
> >>> number of scan-assembler - 2 instead of 3. This patch is fixing that.
> >>>
> >>> Are you sure that there is no problem with the code generation? Did you
> >>> investigate original PR for what it is testing and why it is testing for 
> >>> these 3
> >>> LEAs?
> >>
> >> Well, the problem is due to the change in cost model. This can be reverted 
> >> by simple modification:
> >>
> >> diff --git a/gcc/config/i386/x86-tune-costs.h 
> >> b/gcc/config/i386/x86-tune-costs.h
> >> index c7ac70e..bb5b3e2 100644
> >> --- a/gcc/config/i386/x86-tune-costs.h
> >> +++ b/gcc/config/i386/x86-tune-costs.h
> >> @@ -2253,7 +2253,7 @@ struct processor_costs core_cost = {
> >>     COSTS_N_INSNS (4),                  /*                               
> >> DI */
> >>     COSTS_N_INSNS (4)},                 /*                            
> >> other */
> >>    0,                                   /* cost of multiply per each bit 
> >> set */
> >> -  {COSTS_N_INSNS (8),                  /* cost of a divide/mod for QI */
> >> +  {COSTS_N_INSNS (18),                 /* cost of a divide/mod for QI */
> >>     COSTS_N_INSNS (8),                  /*                          HI */
> >>     /* 8-11 */
> >>     COSTS_N_INSNS (11),                 /*                          SI */
> >>
> >> The original PR was to make better code generation when dividing and 
> >> modulo small integers.
> >>
> >> Ok, maybe I missed something. I'll get back to PR and see if any other 
> >> solution will be proposed
> >> since for now I have nothing.
> > 
> > Please also note that this testcase is intended for generic cost
> > model, and you are testing --with-cpu=corei7. The testcase can be
> > "fixed" by adding "-mtune=generic", but please investigate the tuning
> > change anyway.
> So I ack'd a change from Markus last night to bump the costs for the
> div/mod insns on core2 and a couple other micro-architectures.  They
> weren't as a big a bump as Sebastian's change.
> 
> I've also committed Sebastian's change to use generic tuning on the test.

Thanks.  Lets see how far from reality we need to go.  It should not be too hard
to teach mov/div expansion about the parallelism that should make costs more 
realistic.

Honza

> 
> jeff

Reply via email to