public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: vladimir.mezentsev@oracle.com
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
	       Richard Earnshaw <Richard.Earnshaw@arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, nd <nd@arm.com>
Subject: Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64
Date: Wed, 25 Oct 2017 03:26:00 -0000	[thread overview]
Message-ID: <b37e42b1-e9e0-c37c-8c1f-9ca119fc8a53@oracle.com> (raw)
In-Reply-To: <DB6PR0801MB2053A289718CF265EA55B39383420@DB6PR0801MB2053.eurprd08.prod.outlook.com>

On 10/19/2017 06:07 AM, Wilco Dijkstra wrote:
> Vladimir wrote:
>
> +# Disable floating-point expression contraction
> +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
> +
>
> It looks like this disables fp-contract in all of libgcc...
> What is the the number of FMAs in libgcc before/after?
In original (without my fix) libgcc_s.so:
% objdump -d libgcc_s.so| egrep '(fmadd|fmsub|fnmadd|fnmsub)'|wc -l
  38

In my new libgcc_s.so ( see my fix below)
% objdump -d libgcc_s.so| egrep '(fmadd|fmsub|fnmadd|fnmsub)'|wc -l
8
> If it disables anything other than the ones in complex division, it
> would have an unintended performance impact. It's best to do
> this just for complex division.

On 10/19/2017 10:17 AM, Wilco Dijkstra wrote:
> Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
>> On 10/19/2017 06:37 AM, Richard Earnshaw (lists) wrote:
>>> On 19/10/17 14:07, Wilco Dijkstra wrote:
>>>> Vladimir wrote:
>>>>
>>>> +# Disable floating-point expression contraction
>>>> +LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
>>>> +
>>>>
>>>> It looks like this disables fp-contract in all of libgcc...
>>>> What is the the number of FMAs in libgcc before/after?
>>    How can I find this number ?
>> dis <all functions in libgcc> | grep <all FMAs> | wc
> Eg. objdump -d ~/install/gcc/lib64/libgcc_s.so | grep -c fmadd
> Also grep fmsub, fnmadd, fnmsub.
>
>>> It's probably better to do this with an attribute
>>>
>>>         __attribute__((optimize("fp-contract=off")))
>>>
>>> on the affected functions.
>>    I like your suggestion.
> I don't think this will work in general, IIRC only a few targets correctly
> implement the optimize pragma. Changing the makefile to build only
> __divdc3/__divtc3/__divsc3/__divhc3 without FMA looks like a better
> approach.

Only 3 (_divdc3 / _divhc3 / _divsc3) have FMAs.
The other FMAs are in:
_fixunsdfdi.o _fixunsdfdi_s.o _fixunssfdi.o _fixunssfdi_s.o _muldc3.o
_muldc3_s.o _mulhc3.o _mulhc3_s.o _mulsc3.o _mulsc3_s.o

I suggest the following fix:

% git diff
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index a1a392d..f313556 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -455,6 +455,14 @@ ifeq ($(LIB2_SIDITI_CONV_FUNCS),)
   lib2funcs += $(subst XX,di,$(dwfloatfuncs))
 endif
 
+# Disable FMA (floating-point multiply-add) instructions for complex
division.
+# These instructions can produce different result if two operations
executed separately.
+LIBGCC2_FFP_CONTRAST_CFLAGS = -ffp-contract=off
+LIB2_DIV3_FUNCS = _divdc3 _divhc3 _divsc3
+lib2-div3-o = $(patsubst %,%$(objext),$(LIB2_DIV3_FUNCS))
+lib2-div3-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIV3_FUNCS))
+$(lib2-div3-o) $(lib2-div3-s-o): LIBGCC2_CFLAGS +=
$(LIBGCC2_FFP_CONTRAST_CFLAGS)
+



 If my fix will be approved I send ChangeLog and a patch file tomorrow.

-Vladimir

> However we also need to decide whether this is the best possible fix.
> It will affect accuracy of other inputs as well...
>
> Wilco

  reply	other threads:[~2017-10-25  2:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 13:20 Wilco Dijkstra
2017-10-19 13:52 ` Richard Earnshaw (lists)
2017-10-19 17:13   ` Vladimir Mezentsev
2017-10-19 17:24     ` Wilco Dijkstra
2017-10-25  3:26       ` vladimir.mezentsev [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-02-06  7:20 vladimir.mezentsev
2018-02-06 16:53 ` Joseph Myers
2018-02-07  0:25   ` vladimir.mezentsev
2018-02-07  0:31     ` Joseph Myers
2018-01-25 20:40 vladimir.mezentsev
2018-01-26  3:39 ` Joseph Myers
2018-01-29 20:54   ` vladimir.mezentsev
2018-01-29 21:01     ` Joseph Myers
2018-02-06  8:55       ` vladimir.mezentsev
2018-02-06 17:13         ` Joseph Myers
2017-10-25 17:29 vladimir.mezentsev
2017-10-25 17:29 ` Joseph Myers
2017-10-25 19:19   ` vladimir.mezentsev
2017-10-25 20:04     ` Joseph Myers
2017-10-18 21:32 vladimir.mezentsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b37e42b1-e9e0-c37c-8c1f-9ca119fc8a53@oracle.com \
    --to=vladimir.mezentsev@oracle.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).