public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Wohlferd <dw@LimeGreenSocks.com>
To: Bernd Schmidt <bschmidt@redhat.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Richard Henderson <rth@redhat.com>,
	jason@redhat.com
Cc: segher@kernel.crashing.org, sandra@codesourcery.com,
	Paul_Koning@Dell.com, Jeff Law <law@redhat.com>,
	bernds_cb1@t-online.de,
	Bernd Edlinger <bernd.edlinger@hotmail.de>,
	Andrew Haley <aph@redhat.com>,
	David Wohlferd <dw@LimeGreenSocks.com>
Subject: Re: Wonly-top-basic-asm
Date: Mon, 08 Feb 2016 03:46:00 -0000	[thread overview]
Message-ID: <56B80F57.9020606@LimeGreenSocks.com> (raw)
In-Reply-To: <56A9C134.1030500@LimeGreenSocks.com>

[-- Attachment #1: Type: text/plain, Size: 8952 bytes --]

Hey Bernd.

I replied with a patch that includes most of the changes you asked for 
(see inline below).  Were you waiting on me for something more?

I have cleaned up the testcases so they aren't so i386-specific, but 
otherwise this patch (attached) is the same.  Let me know if there is 
something more I need to do here.

Thanks,
dw

On 1/27/2016 11:20 PM, David Wohlferd wrote:
> Rumors that I earn a commission for every person I switch to the 
> "extended asm" plan are completely unfounded... :)
>
> That said, I truly believe there are very few cases where using basic 
> asm within a function makes sense.  What's more, either they currently 
> work incorrectly and need to be found and fixed, or they are going to 
> take a performance hit when the new "clobber everything" semantics are 
> implemented.  So yeah, I pushed pretty hard to have the docs say 
> "DON'T USE IT!"
>
> But reading it all again, you are right:  It's too much.
>
> On 1/25/2016 4:25 AM, Bernd Schmidt wrote:
>> On 01/24/2016 11:23 PM, David Wohlferd wrote:
>>> +Wonly-top-basic-asm
>>> +C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning
>>> +Warn on unsafe uses of basic asm.
>>
>> Maybe just -Wbasic-asm?
>
> Hmm.  Maybe.  I've never been completely satisfied with that name. But 
> wouldn't this sound like it would warn on all uses of basic asm?  The 
> intent is to only flag the ones in functions.  They are the ones with 
> all the problems.
>
> What would you say to -Wbasic-asm-in-function?  A little verbose...
>
>>> +    /* Warn on basic asm used inside of functions,
>>> +       EXCEPT when in naked functions. Also allow asm(""). */
>>
>> Two spaces after a sentence.
>
> Fixed.
>
>>> +    if (warn_only_top_basic_asm && (TREE_STRING_LENGTH (str) != 1) )
>>
>> Unnecessary parens, and extra space before closing paren.
>
> Fixed.
>
>>> +          if (warn_only_top_basic_asm &&
>>> +              (TREE_STRING_LENGTH (string) != 1))
>>
>> Extra parens, and && goes first on the next line.
>
> Fixed.
>
>>> +              warning_at(asm_loc, OPT_Wonly_top_basic_asm,
>>
>> Space before "(".
>
> Fixed.
>
>>> +                "asm statement in function does not use extended 
>>> syntax");
>>
>> Could break that into ".." "..." over two lines so as to keep 
>> indentation.
>
> Fixed.
>
>>> -asm ("");
>>> +asm ("":::);
>>
>> Is that necessary? As far as I can tell we're treating these equally.
>
> While you are correct that today they are treated (nearly) equally, if 
> Jeff does what he plans for v7, asm("") is going to translate (on x64) 
> to:
>
> asm("":::"rax", "rbx", "rcx", "rdx", "r8", "r9", "r10", "r11", "r12", 
> "r13", "r14", "r15", "rdi", "rsi", "rbp", "cc", "memory");
>
> Given that, it seemed appropriate for the docs to start steering 
> people away from basic.  This particular instance was just something 
> that was mentioned during the discussion.
>
> However, that's for someday.  Maybe "someday" will turn into some 
> other solution.   And since I'm not prepared to go thru all the docs 
> and change all the other basic asms at this time, I removed this change.
>
>>> @@ -7487,6 +7490,8 @@
>>>   consecutive in the output, put them in a single multi-instruction 
>>> @code{asm}
>>>   statement. Note that GCC's optimizers can move @code{asm} statements
>>>   relative to other code, including across jumps.
>>> +Using inputs and outputs with extended @code{asm} can help 
>>> correctly position
>>> +your asm.
>>
>> Not sure this is needed either. Sounds a bit like advertising :) In 
>> general the doc changes seem much too verbose to me.
>
> I didn't think about this until it was brought up during the 
> discussion.  But once it was pointed out to me, it made sense.
>
> However, at your suggestion I have removed this.
>
>>> +Extended @code{asm}'s @samp{%=} may help resolve this.
>>
>> Same here. I think the block that recommends extended asm is good 
>> enough. I think the next part could be shrunk significantly too.
>
> Removed.
>
>>> -Here is an example of basic @code{asm} for i386:
>>> +Basic @code{asm} statements within functions do not perform an 
>>> implicit
>>> +"memory" clobber (@pxref{Clobbers}).  Also, there is no implicit 
>>> clobbering
>>> +of @emph{any} registers, so (other than "naked" functions which 
>>> follow the
>>
>> "other than in"? Also @code{naked} maybe. 
>
> It works for me either way.  Since it bothers you, I changed it.
>
>> I'd place a note about clobbering after the existing "To access C 
>> data, it is better to use extended asm".
>>
>>> +ABI rules) changed registers must be restored to their original 
>>> value before
>>> +exiting the @code{asm}.  While this behavior has not always been 
>>> documented,
>>> +GCC has worked this way since at least v2.95.3.  Also, lacking 
>>> inputs and
>>> +outputs means that GCC's optimizers may have difficulties consistently
>>> +positioning the basic @code{asm} in the generated code.
>>
>> The existing text already mentions ordering issues. Lose this block.
>
> I've removed the rest of the paragraph after "Also"
>
> Wait, didn't you tell me to remove the other mention of 'ordering'? I 
> think I've removed all of them now.  Not a huge loss, but was that 
> what you intended?
>
>>> +The concept of ``clobbering'' does not apply to basic @code{asm} 
>>> statements
>>> +outside of functions (aka top-level asm).
>>
>> Stating the obvious?
>
> I don't actually agree with this one.  However I do agree with your 
> comment re being too verbose.  Since the new sample shows how to do 
> this (using extended asm for clobbers), I have removed this.
>
>>> +@strong{Warning!} This "clobber nothing" behavior may be different 
>>> than how
>>
>> Ok there is precedent for this, but it's spelt "@strong{Warning:}" in 
>> all other cases. 
>
> Fixed.
>
>> Still, I'd probably also shrink this paragraph and put a note about 
>> lack of C semantics and possibly different behaviour from other 
>> compilers near the top, where we say that extended asm is better in 
>> most cases.
>>
>>> +other compilers treat basic @code{asm}, since the C standards for the
>>> +@code{asm} statement provide no guidance regarding these 
>>> semantics.  As a
>>> +result, @code{asm} statements that work correctly on other 
>>> compilers may not
>>> +work correctly with GCC (and vice versa), even though they both 
>>> compile
>>> +without error.  Also, there is discussion underway about changing 
>>> GCC to
>>> +have basic @code{asm} clobber at least memory and perhaps some (or 
>>> all)
>>> +registers.  If implemented, this change may fix subtle problems with
>>> +existing @code{asm} statements.  However it may break or slow down 
>>> ones that
>>> +were working correctly.
>>
>> How would such a change break anything? I'd also not mention 
>> discussion underway, just say "Future versions of GCC may treat basic 
>> @code{asm} as clobbering memory".
>
> Removed 'discussion underway', but kept references to clobbering 
> registers.  That's Jeff's expressed intent, and part of why I believe 
> people will want to find these statements.
>
>>> +If your existing code needs clobbers that GCC's basic @code{asm} is 
>>> not
>>> +providing, or if you want to 'future-proof' your asm against possible
>>> +changes to basic @code{asm}'s semantics, use extended @code{asm}.
>>
>> Recommending it too often. Lose this.
>>
>>> +Extended @code{asm} allows you to specify what (if anything) needs 
>>> to be
>>> +clobbered for your code to work correctly.
>>
>> And again.
>
> I believe I have removed and replaced all the recurring redundant 
> repetitiveness.
>
>>> You can use @ref{Warning
>>> +Options, @option{-Wonly-top-basic-asm}} to locate basic @code{asm}
>>
>> I think just plain @option is usual.
>
> You are recommending I remove the link to the warning options? While 
> I'm normally a big fan of links, I defer to your judgement. Removed.
>
>>> +statements that may need changes, and refer to
>>> +@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to 
>>> convert
>>> +from basic asm to extended asm} for information about how to 
>>> perform the
>>> +conversion.
>>
>> A link is probably good if we have such a page.
>
> We do have such a page, but it was written by the same "too verbose" 
> guy that wrote this patch.  Might be worth a review if you have a minute.
>
>>> +Here is an example of top-level basic @code{asm} for i386 that 
>>> defines an
>>> +asm macro.  That macro is then invoked from within a function using
>>> +extended @code{asm}:
>>
>> The updated example also looks good.
>
> There are legitimate uses for basic asm.  While this sample is still 
> trivial, it shows a much more important concept than the old one.
>
>> I think I'm fine with the concept 
>
> Thanks for the detailed review.
>
>> but I'd like to see an updated patch with better docs.
>
> Updated patch attached.  Now includes testsuites.  The updated web 
> page is at http://www.limegreensocks.com/gcc/Basic-Asm.html
>
> dw


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 24414Q.patch --]
[-- Type: text/x-patch; name="24414Q.patch", Size: 8617 bytes --]

Index: gcc/c-family/c.opt
===================================================================
--- gcc/c-family/c.opt	(revision 233206)
+++ gcc/c-family/c.opt	(working copy)
@@ -585,6 +585,10 @@
 C++ ObjC++ Var(warn_namespaces) Warning
 Warn on namespace definition.
 
+Wonly-top-basic-asm
+C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning
+Warn on unsafe uses of basic asm.
+
 Wsized-deallocation
 C++ ObjC++ Var(warn_sized_deallocation) Warning EnabledBy(Wextra)
 Warn about missing sized deallocation functions.
Index: gcc/c/c-parser.c
===================================================================
--- gcc/c/c-parser.c	(revision 233206)
+++ gcc/c/c-parser.c	(working copy)
@@ -5972,7 +5972,18 @@
   labels = NULL_TREE;
 
   if (c_parser_next_token_is (parser, CPP_CLOSE_PAREN) && !is_goto)
+  {
+    /* Warn on basic asm used inside of functions, 
+       EXCEPT when in naked functions.  Also allow asm(""). */
+    if (warn_only_top_basic_asm && TREE_STRING_LENGTH (str) != 1)
+      if (lookup_attribute ("naked", 
+                            DECL_ATTRIBUTES (current_function_decl)) 
+          == NULL_TREE)
+        warning_at (asm_loc, OPT_Wonly_top_basic_asm, 
+                    "asm statement in function does not use extended syntax");
+
     goto done_asm;
+  }
 
   /* Parse each colon-delimited section of operands.  */
   nsections = 3 + is_goto;
Index: gcc/cp/parser.c
===================================================================
--- gcc/cp/parser.c	(revision 233206)
+++ gcc/cp/parser.c	(working copy)
@@ -18021,6 +18021,8 @@
   bool goto_p = false;
   required_token missing = RT_NONE;
 
+  location_t asm_loc = cp_lexer_peek_token (parser->lexer)->location;
+
   /* Look for the `asm' keyword.  */
   cp_parser_require_keyword (parser, RID_ASM, RT_ASM);
 
@@ -18179,6 +18181,17 @@
 	  /* If the extended syntax was not used, mark the ASM_EXPR.  */
 	  if (!extended_p)
 	    {
+	      /* Warn on basic asm used inside of functions,
+	         EXCEPT when in naked functions.  Also allow asm(""). */
+	      if (warn_only_top_basic_asm
+	          && TREE_STRING_LENGTH (string) != 1)
+	        if (lookup_attribute("naked",
+	                             DECL_ATTRIBUTES (current_function_decl))
+	            == NULL_TREE)
+	          warning_at (asm_loc, OPT_Wonly_top_basic_asm,
+	                      "asm statement in function does not use extended"
+                              " syntax");
+
 	      tree temp = asm_stmt;
 	      if (TREE_CODE (temp) == CLEANUP_POINT_EXPR)
 		temp = TREE_OPERAND (temp, 0);
Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi	(revision 233206)
+++ gcc/doc/extend.texi	(working copy)
@@ -7458,7 +7458,8 @@
 @end table
 
 @subsubheading Remarks
-Using extended @code{asm} typically produces smaller, safer, and more
+Using extended @code{asm} (@pxref{Extended Asm}) typically produces smaller,
+safer, and more
 efficient code, and in most cases it is a better solution than basic
 @code{asm}.  However, there are two situations where only basic @code{asm}
 can be used:
@@ -7516,11 +7517,51 @@
 Basic @code{asm} provides no
 mechanism to provide different assembler strings for different dialects.
 
-Here is an example of basic @code{asm} for i386:
+Basic @code{asm} statements do not perform an implicit "memory" clobber
+(@pxref{Clobbers}).  Also, there is no implicit clobbering of @emph{any}
+registers, so (other than in @code{naked} functions which follow the ABI
+rules) changed registers must be restored to their original value before
+exiting the @code{asm}.  While this behavior has not always been
+documented, GCC has worked this way since at least v2.95.3.
 
+@strong{Warning:} This "clobber nothing" behavior may be different than how
+other compilers treat basic @code{asm}, since the C standards for the
+@code{asm} statement provide no guidance regarding these semantics.  As a
+result, @code{asm} statements that work correctly on other compilers may not
+work correctly with GCC (and vice versa), even though they both compile
+without error.
+
+Future versions of GCC may change basic @code{asm} to clobber memory and
+perhaps some (or all) registers.  This change may fix subtle problems with
+existing @code{asm} statements.  However it may break or slow down ones
+that were working correctly.  To ``future-proof'' your asm against possible
+changes to basic @code{asm}'s semantics, use extended @code{asm}.
+
+You can use @option{-Wonly-top-basic-asm} to locate basic @code{asm}
+statements that may need changes, and refer to
+@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to convert
+from basic asm to extended asm} for information about how to perform the
+conversion.
+
+Here is an example of top-level basic @code{asm} for i386 that defines an
+asm macro.  That macro is then invoked from within a function using
+extended @code{asm}:
+
 @example
-/* Note that this code will not compile with -masm=intel */
-#define DebugBreak() asm("int $3")
+/* Define macro at file scope with basic asm. */
+/* Add macro parameter p to eax. */
+asm(".macro test p\n\t"
+    "addl $\\p, %eax\n\t"
+    ".endm");
+
+/* Use macro in function using extended asm.  It needs */
+/* the "cc" clobber since the flags are changed and uses */
+/* the "a" constraint since it modifies eax. */
+int DoAdd(int value)
+@{
+   asm("test 5" : "+a" (value) : : "cc");
+   return value;
+@}
 @end example
 
 @node Extended Asm
@@ -8047,7 +8088,7 @@
 for @code{d} by specifying both constraints.
 
 @anchor{FlagOutputOperands}
-@subsection Flag Output Operands
+@subsubsection Flag Output Operands
 @cindex @code{asm} flag output operands
 
 Some targets have a special register that holds the ``flags'' for the
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 233206)
+++ gcc/doc/invoke.texi	(working copy)
@@ -5728,6 +5728,21 @@
 a structure that has been marked with the @code{designated_init}
 attribute.
 
+@item -Wonly-top-basic-asm @r{(C and C++ only)}
+Warn if basic @code{asm} statements are used inside a function (i.e. not at
+top-level/file scope).
+
+When used inside of functions, basic @code{asm} can result in unexpected and
+unwanted variations in behavior between compilers due to how registers are
+handled when calling the asm (@pxref{Basic Asm}).  The lack of input and
+output constraints (@pxref{Extended Asm}) can also make it difficult for
+optimizers to correctly and consistently position the output relative to
+other code.
+
+Functions that are marked with the @option{naked} attribute (@pxref{Function
+Attributes}) and @code{asm} statements with an empty instruction string are
+excluded from this check.
+
 @item -Whsa
 Issue a warning when HSAIL cannot be emitted for the compiled function or
 OpenMP construct.
Index: gcc/testsuite/c-c++-common/Wonly-top-basic-asm-2.c
===================================================================
--- gcc/testsuite/c-c++-common/Wonly-top-basic-asm-2.c	(revision 0)
+++ gcc/testsuite/c-c++-common/Wonly-top-basic-asm-2.c	(working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target naked_functions } */
+/* { dg-options "-Wonly-top-basic-asm" } */
+
+int __attribute__((naked))
+func (int x, int y)
+{
+  /* basic asm should not warn in naked functions. */
+   asm(" "); /* no warning */
+}
+
+int main(int argc, char *argv[])
+{
+   return func(argc, argc);
+}
Index: gcc/testsuite/c-c++-common/Wonly-top-basic-asm.c
===================================================================
--- gcc/testsuite/c-c++-common/Wonly-top-basic-asm.c	(revision 0)
+++ gcc/testsuite/c-c++-common/Wonly-top-basic-asm.c	(working copy)
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+/* { dg-options "-Wonly-top-basic-asm" } */
+
+#if defined(__i386__) || defined(__x86_64__)
+/* acceptable */
+register int b asm("esi");
+#else
+int b = 3;
+#endif
+
+/* acceptable */
+int foo asm ("myfoo") = 2;
+
+/* acceptable */
+asm (" ");
+
+/* acceptable */
+int func (int x, int y) asm ("MYFUNC");
+
+int main(int argc, char *argv[])
+{
+#if defined(__i386__) || defined(__x86_64__)
+   /* acceptable */
+   register int a asm("edi");
+#else
+   int a = 2;
+#endif
+
+   /* acceptable */
+   asm(" "::"r"(a), "r" (b));
+
+   /* acceptable */
+   asm goto (""::::done);
+
+   /* acceptable */
+   asm("");
+
+   /* warning */
+   asm(" "); /* { dg-warning "does not use extended syntax" } */
+
+  done:
+   return 0;
+}

  reply	other threads:[~2016-02-08  3:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-24 22:24 Wonly-top-basic-asm David Wohlferd
2016-01-25 12:25 ` Wonly-top-basic-asm Bernd Schmidt
2016-01-28  7:21   ` Wonly-top-basic-asm David Wohlferd
2016-02-08  3:46     ` David Wohlferd [this message]
2016-02-08  6:45       ` AW: Wonly-top-basic-asm Bernd Edlinger
2016-02-08 20:15         ` David Wohlferd
2016-02-10 23:50         ` David Wohlferd
2016-02-11  6:51           ` AW: " Bernd Edlinger
2016-02-12  7:01             ` David Wohlferd
2016-02-11 15:40           ` Bernd Schmidt
2016-02-11 16:03             ` Sandra Loosemore
2016-02-12  7:08               ` David Wohlferd
2016-02-12  7:05             ` David Wohlferd
2016-02-12 12:51               ` Bernd Schmidt
2016-02-13  1:03                 ` Sandra Loosemore
2016-02-14  4:00                   ` David Wohlferd
2016-02-20  1:03                     ` David Wohlferd
2016-02-20 12:08                       ` Wonly-top-basic-asm Bernd Edlinger
2016-02-21 10:28                         ` Wonly-top-basic-asm David Wohlferd
2016-02-26 15:10                           ` Wonly-top-basic-asm Bernd Schmidt
2016-02-29  7:02                             ` Wonly-top-basic-asm David Wohlferd
2016-03-11  0:56                               ` Wonly-top-basic-asm David Wohlferd
2016-03-14 15:29                                 ` Wonly-top-basic-asm Bernd Schmidt
2016-03-17  5:24                                   ` Wonly-top-basic-asm David Wohlferd
2016-03-18 13:32                                     ` Wonly-top-basic-asm Bernd Schmidt
2016-03-18 15:01                                       ` Wonly-top-basic-asm Richard Biener
2016-03-18 19:14                                     ` Wonly-top-basic-asm Bernd Schmidt
2016-02-14  3:57                 ` AW: Wonly-top-basic-asm David Wohlferd
2016-01-26  0:32 ` Wonly-top-basic-asm Segher Boessenkool
2016-01-26 12:11   ` Wonly-top-basic-asm Bernd Schmidt
2016-01-26 16:12     ` Wonly-top-basic-asm Segher Boessenkool
2016-01-26 23:38       ` Wonly-top-basic-asm David Wohlferd
2016-02-16 14:03 ` Wonly-top-basic-asm Jan Hubicka
2016-02-16 20:02   ` Wonly-top-basic-asm Bernd Edlinger

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=56B80F57.9020606@LimeGreenSocks.com \
    --to=dw@limegreensocks.com \
    --cc=Paul_Koning@Dell.com \
    --cc=aph@redhat.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=bernds_cb1@t-online.de \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=law@redhat.com \
    --cc=rth@redhat.com \
    --cc=sandra@codesourcery.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).