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.
jeff
