public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marc Glisse <marc.glisse@inria.fr>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com,
	    Joseph Myers <joseph@codesourcery.com>,
	jason@redhat.com, nathan@acm.org,     polacek@redhat.com
Subject: Re: [PATCH 2/2] asm inline
Date: Sun, 02 Dec 2018 18:38:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.21.1812021858140.14305@stedding.saclay.inria.fr> (raw)
In-Reply-To: <20181202174449.GA3803@gate.crashing.org>

On Sun, 2 Dec 2018, Segher Boessenkool wrote:

>> what is the point of !!count when we take the max with 1 on the very
>> next line? Is it in prevision of a time when we may remove the MAX? (sorry
>> if this was covered in previous iterations)
>>
>> By the way, not related to the patch, but I wonder why we cannot have a
>> cost of 0.
>
> That exactly is the point :-)  My code still works if you remove that MAX
> expression, as hopefully we will some day.  Right now GCC will of course
> optimise it to "count = 1;", but writing it like that doesn't make the
> intent clear.
>
> I think this workaround is here because otherwise we get infinite recursion
> in the inliner, but that of course should be fixed, not worked around.
> Ideally.  If anyone ever has time for it.  :-)

Thanks.

Note that I may have 2 or 3 such asm per floating point operation, which
could be enough to skew inlining decisions. On the other hand, the
protected operations can never be optimized (that's the whole point of
the asm), which is a reason not to inline too much. I never really had a
problem, I was just curious.

>> My main use of inline asm is as an optimization barrier:
>> asm("":"+gx"(local_var))
>> possibly marked volatile to prevent more optimizations. I certainly
>> expect it to generate exactly 0 instruction in most cases. Although if I
>> am not careful it could easily generate moves from x87 to sse/memory for
>> instance. I guess a minimal cost is safer and doesn't affect decisions too
>> badly.
>
> This is only for inlining; GCC _does_ know such asms are cost 0, and uses
> that for all other purposes.
>
> ("gx", btw?  Is that a typo?  Or, on what target is "x" useful here?)

(context: -frounding-math doesn't work, so I have to protect double values)
On x64_64, "x" is for SSE registers, and those are not included in "g". 
When "gx" fails (ICE on old gcc, bad codegen with llvm) I use "mx" ("gx" 
does not really bring much compared to "mx" for a double) or even just "x" 
since "m" doesn't quite work as I would like. I have this rather sad code 
(slightly edited) where no 2 platforms use the same letter:

# if defined __SSE2_MATH__
   asm volatile ("" : "+gx"(x) );
# elif (defined __i386__ || defined __x86_64__)
   asm volatile ("" : "+mt"(x) );
# elif (defined __VFP_FP__ && !defined __SOFTFP__) || defined __aarch64__
   asm volatile ("" : "+gw"(x) );
# elif defined __powerpc__ || defined __POWERPC__
   asm volatile ("" : "+gd"(x) );
# elif defined __sparc
   asm volatile ("" : "+ge"(x) );
# elif defined __ia64
   asm volatile ("" : "+gf"(x) );
# else
   asm volatile ("" : "+g"(x) );
# endif

-- 
Marc Glisse

  reply	other threads:[~2018-12-02 18:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-02 16:38 [PATCH v2 0/2] asm qualifiers (PR55681) and " Segher Boessenkool
2018-12-02 16:39 ` [PATCH 1/2] asm qualifiers (PR55681) Segher Boessenkool
2018-12-03 22:20   ` Joseph Myers
2018-12-05 21:47   ` Jason Merrill
2018-12-05 23:02     ` Segher Boessenkool
2018-12-02 16:40 ` [PATCH 2/2] asm inline Segher Boessenkool
2018-12-02 17:23   ` Marc Glisse
2018-12-02 17:45     ` Segher Boessenkool
2018-12-02 18:38       ` Marc Glisse [this message]
2018-12-04 15:31   ` Richard Sandiford
2018-12-06  3:03     ` Segher Boessenkool
2018-12-06 18:11 ` [PATCH v2 0/2] asm qualifiers (PR55681) and " Segher Boessenkool
2018-12-06 18:15   ` Jakub Jelinek
2018-12-06 18:19     ` Joseph Myers
2018-12-06 18:54     ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2018-10-30 18:01 [PATCH 0/2] asm qualifiers (PR55681) and asm input Segher Boessenkool
2018-10-30 18:41 ` [PATCH 2/2] asm inline Segher Boessenkool
2018-10-30 18:58   ` Marek Polacek
2018-11-11 21:33   ` Martin Sebor
2018-11-11 22:01     ` Segher Boessenkool
2018-11-11 23:41       ` Martin Sebor
2018-11-12  0:19         ` Segher Boessenkool
2018-11-30 13:14   ` Richard Biener

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=alpine.DEB.2.21.1812021858140.14305@stedding.saclay.inria.fr \
    --to=marc.glisse@inria.fr \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=nathan@acm.org \
    --cc=polacek@redhat.com \
    --cc=segher@kernel.crashing.org \
    /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).