On Mon, 31 Mar 2025, Jakub Jelinek wrote:

> On Mon, Mar 31, 2025 at 03:12:56PM +0200, Richard Biener wrote:
> > The following fixes ix86_handle_option to properly handle -mno-sse4
> > which is always handled as -msse4 with value unset.  I've verified
> > no other OPT_mno_* is left around.
> > 
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > 
> > This error goes back quite some time, I'm not sure how prevalent
> > the use of -mno-sse4 is.  In fact I have no idea why we have
> > OPT_mno_sse4 at all...
> 
> That is because SSE4 is SSE4.1 + SSE4.2.
> So for -msse4 we want it to act as -msse4.2 and for -mno-sse4
> to act as -mno-sse4.1

Yes, but it seems ix86_handle_option handles this via
OPTION_MASK_ISA_SSE4_SET vs. ~OPTION_MASK_ISA_SSE4_UNSET.  So the
question is what the -mno-sse4 options entry does.  I'll note
that ix86_handle_option also unsets flags in ix86_isa_flags2
with -mno-sse4 but the mno-sse4 options entry does not indicate
that.

Richard.

> > msse4
> > Target RejectNegative Mask(ISA_SSE4_2) Var(ix86_isa_flags) Save
> > Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 built-in functions 
> > and code generation.
> > 
> > mno-sse4
> > Target RejectNegative InverseMask(ISA_SSE4_1) Var(ix86_isa_flags) Save
> > Do not support SSE4.1 and SSE4.2 built-in functions and code generation.
> > 
> > but we end up building
> > 
> > $3 = {opt_index = 2231, warn_message = 0x0, arg = 0x0, 
> >   orig_option_with_args_text = 0x440d108 "-msse4", canonical_option = {
> >     0x440d108 "-msse4", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1, 
> >   value = 0, mask = 0, errors = 0}
> > 
> > from -mno-sse4 in target("") via ix86_valid_target_attribute_inner_p.
> > 
> > OK?  Any clarification on what the above is about?
> > 
> > Richard.
> > 
> >     PR target/119549
> >     * common/config/i386/i386-common.cc (ix86_handle_option):
> >     Handle OPT_mno_sse4 via OPT_msse4 and looking at value.
> > 
> >     * gcc.target/i386/pr119549.c: New testcase.
> > ---
> >  gcc/common/config/i386/i386-common.cc    | 21 ++++++++++++---------
> >  gcc/testsuite/gcc.target/i386/pr119549.c | 15 +++++++++++++++
> >  2 files changed, 27 insertions(+), 9 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr119549.c
> > 
> > diff --git a/gcc/common/config/i386/i386-common.cc 
> > b/gcc/common/config/i386/i386-common.cc
> > index 80aec3244bc..296df3b3230 100644
> > --- a/gcc/common/config/i386/i386-common.cc
> > +++ b/gcc/common/config/i386/i386-common.cc
> > @@ -1519,15 +1519,18 @@ ix86_handle_option (struct gcc_options *opts,
> >        return true;
> >  
> >      case OPT_msse4:
> > -      opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
> > -      opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
> > -      return true;
> > -
> > -    case OPT_mno_sse4:
> > -      opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
> > -      opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
> > -      opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
> > -      opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
> > +      if (value)
> > +   {
> > +     opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE4_SET;
> > +     opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_SET;
> > +   }
> > +      else
> > +   {
> > +     opts->x_ix86_isa_flags &= ~OPTION_MASK_ISA_SSE4_UNSET;
> > +     opts->x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_UNSET;
> > +     opts->x_ix86_isa_flags2 &= ~OPTION_MASK_ISA2_SSE4_UNSET;
> > +     opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA2_SSE4_UNSET;
> > +   }
> >        return true;
> >  
> >      case OPT_msse4a:
> 
> For OPT_msse4 that looks reasonable, but I wonder if the old code shouldn't
> be kept for OPT_mno_sse4.  When I just try to compile something with
> -O2 -mavx2 -mno-sse4
> previously this would make it like -O2 -mssse3, now it will act as -O2 -mavx2.
> E.g. compile
> #if __SSSE3__
> int i;
> #endif
> #if __AVX2__
> int j;
> #endif
> 
> I wonder what OPT_mno_sse4 with !value would actually mean though (if it
> ever happens).
> 
>       Jakub
> 
> 

-- 
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Reply via email to