This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, testcase] PR82767 Fix scan-assembler patterns in i386/pr71321.c
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "Peryt, Sebastian" <sebastian dot peryt at intel dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Sat, 16 Dec 2017 19:26:52 +0100
- Subject: Re: [Patch, testcase] PR82767 Fix scan-assembler patterns in i386/pr71321.c
- Authentication-results: sourceware.org; auth=none
- References: <17623B198193D741876BD81A6E3AE5AD3C58CA5D@irsmsx111.ger.corp.intel.com> <CAFULd4Z=xs_4i61jaxTvUN-dZDm5WCysBtm9in2=DSOQzDWNZw@mail.gmail.com> <17623B198193D741876BD81A6E3AE5AD3C58CD51@irsmsx111.ger.corp.intel.com> <CAFULd4ZoTd4Wk9f2ajY6D=Kv96AuicyiKnupb4=VLBRKe5rTxQ@mail.gmail.com> <8bfe75c7-bc25-7da0-3bbc-c697c3579728@redhat.com>
> On 11/06/2017 12:11 AM, Uros Bizjak wrote:
> > On Mon, Nov 6, 2017 at 12:19 AM, Peryt, Sebastian
> > <sebastian.peryt@intel.com> wrote:
> >>> On Sun, Nov 5, 2017 at 12:14 PM, Peryt, Sebastian <sebastian.peryt@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