On Fri, Feb 5, 2021 at 10:31 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > On Fri, Feb 5, 2021 at 10:29 AM Jakub Jelinek <ja...@redhat.com> wrote: > > > > Hi! > > > > As written in the PR, TARGET_QIMODE_MATH was meant to be set for all > > tunings and it was the case for GCC <= 7, but as the number of > > PROCESSOR_* enumerators grew, some AMD tunings (which are at the end > > of the list) over time got enumerators with values >= 32 and > > TARGET_QIMODE_MATH became disabled for them, in GCC 8 for 2 > > tunings, in GCC 9 for 7 tunings, in GCC 10 for 8 tunings, and > > on the trunk for 11 tunings. > > Ouch. > > > The following patch fixes it by using uhwis rather than uints > > and gives them also symbolic names. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > 2021-02-05 Jakub Jelinek <ja...@redhat.com> > > > > PR target/98957 > > * config/i386/i386-options.c (m_NONE, m_ALL): Define. > > * config/i386/x86-tune.def (X86_TUNE_BRANCH_PREDICTION_HINTS, > > X86_TUNE_PROMOTE_QI_REGS): Use m_NONE instead of 0U. > > (X86_TUNE_QIMODE_MATH): Use m_ALL instead of ~0U. > > OK for mainline and backports. > > Thanks, > Uros. > > > --- gcc/config/i386/i386-options.c.jj 2021-01-14 19:34:06.041425286 +0100 > > +++ gcc/config/i386/i386-options.c 2021-02-04 16:30:18.424999701 +0100 > > @@ -98,6 +98,8 @@ along with GCC; see the file COPYING3. > > #endif > > > > /* Processor feature/optimization bitmasks. */ > > +#define m_NONE HOST_WIDE_INT_0U > > +#define m_ALL (~HOST_WIDE_INT_0U)
Perhaps HOST_WIDE_INT_M1U can be used here? Uros. > > #define m_386 (HOST_WIDE_INT_1U<<PROCESSOR_I386) > > #define m_486 (HOST_WIDE_INT_1U<<PROCESSOR_I486) > > #define m_PENT (HOST_WIDE_INT_1U<<PROCESSOR_PENTIUM) > > --- gcc/config/i386/x86-tune.def.jj 2021-01-04 10:25:45.175162012 +0100 > > +++ gcc/config/i386/x86-tune.def 2021-02-04 16:32:20.239645476 +0100 > > @@ -580,15 +580,15 @@ DEF_TUNE (X86_TUNE_AVOID_VECTOR_DECODE, > > on simulation result. But after P4 was made, no performance benefit > > was observed with branch hints. It also increases the code size. > > As a result, icc never generates branch hints. */ > > -DEF_TUNE (X86_TUNE_BRANCH_PREDICTION_HINTS, "branch_prediction_hints", 0U) > > +DEF_TUNE (X86_TUNE_BRANCH_PREDICTION_HINTS, "branch_prediction_hints", > > m_NONE) > > > > /* X86_TUNE_QIMODE_MATH: Enable use of 8bit arithmetic. */ > > -DEF_TUNE (X86_TUNE_QIMODE_MATH, "qimode_math", ~0U) > > +DEF_TUNE (X86_TUNE_QIMODE_MATH, "qimode_math", m_ALL) > > > > /* X86_TUNE_PROMOTE_QI_REGS: This enables generic code that promotes all > > 8bit > > arithmetic to 32bit via PROMOTE_MODE macro. This code generation scheme > > is usually used for RISC targets. */ > > -DEF_TUNE (X86_TUNE_PROMOTE_QI_REGS, "promote_qi_regs", 0U) > > +DEF_TUNE (X86_TUNE_PROMOTE_QI_REGS, "promote_qi_regs", m_NONE) > > > > /* X86_TUNE_EMIT_VZEROUPPER: This enables vzeroupper instruction insertion > > before a transfer of control flow out of the function. */ > > > > Jakub > >
