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: [RFC] [Patch X86_64]: Pass to split FMA to MUL and ADD


Hi Maarc,

> -----Original Message-----
> From: Marc Glisse [mailto:marc.glisse@inria.fr]
> Sent: Tuesday, November 7, 2017 12:52 PM
> To: Kumar, Venkataramanan <Venkataramanan.Kumar@amd.com>
> Cc: gcc-patches@gcc.gnu.org; Dharmakan, Rohit arul raj
> <Rohitarulraj.Dharmakan@amd.com>; Jan Hubicka (hubicka@ucw.cz)
> <hubicka@ucw.cz>; Uros Bizjak <ubizjak@gmail.com>
> Subject: Re: [RFC] [Patch X86_64]: Pass to split FMA to MUL and ADD
> 
> On Tue, 7 Nov 2017, Kumar, Venkataramanan wrote:
> 
> > The attached patch implements an RTL pass which splits generated FMA
> instruction into MUL/ADD sequence.
> 
> That seems wrong if the user explicitly asked for FMA in his program, unless
> you have a way to recognize which FMA instructions come from user calls to
> fma and which were invented by gcc. Why not disable the gimple
> transformation that creates FMA instead ?
We split only for reduction pattern and not all FMAs. 
By user calls do you mean FMA in inline ASM calls? We don't split in that case.  

> That seems wrong if the user explicitly asked for FMA in his program 
Do you mean using function attribute or command line option?

Doing in Gimple would be more generic. 
This implementation is profitable only for few sub-targets of x86 where latency of floating point ADD is less than that of FMA (ex Zen).

> 
> > 	* doc/invoke.texi (SPARC Options): Document -msplit-fma.
> 
> Sparc really?

Sorry I copied from a change log and forgot to remove it. Thanks for pointing that.

> 
> --
> Marc Glisse

Regards,
Venkat.


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