This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR target/38201: -mfma/-mavx and -msse5/-msse4a don't work together


H.J. Lu wrote:

Also, we have to deal with Intel FMA and SSE5. Since there is no silicon,
we can't use -mtune= to guide us. That leaves to -msse5 and -mfma.
If we allow this combination, we have to pick one arbitrarily.
I think that the problematic insns are only various FMA instructions
that fight for generic (a * b) + c expressions. We currently have
-mno-fused-madd that disables generic AMD FMA while still leaves SSE5
intrinsics version of FMA enabled. There is also -mfma that will
enable Intel intrinsics and generic FMA.

We can solve this by saying that -mfma implies -mno-fused-madd. This
still leaves various intrinsic FMA implementations (Intel and AMD)
enabled, while defaulting to Intel version of generic FMA when -mfma
is in effect. This can further be refined with various -mtune options
in future if some target processor prefers AMD generic FMA
implementation over Intel one.

This will also cover future processors that will eventually implement
SSE5 and FMA.

Does this looks OK?


There are


mfused-madd
Target Report InverseMask(NO_FUSED_MADD, FUSED_MADD) Save
Enable automatic generation of fused floating point multiply-add instructions
if the ISA supports such instructions.  The -mfused-madd option is on by
default.

Now, its comment is no long true for Intel FMA and -mfma will turn it off
by default.

What should happen with permutation of -mfused-madd/-mfma/-msse5?

This is IMO the only combination where gcc should error out, since we have a real clash between two insn sets.


Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]