Re: inline asm and multi-alternative constraints

[David Wohlferd <dw at LimeGreenSocks dot com>]

On 11/2/2015 3:43 PM, Sandra Loosemore wrote:
> On 11/02/2015 04:06 PM, Jeff Law wrote:
> > On 10/30/2015 09:09 PM, David Wohlferd wrote:
> > > I have updated the non-md text with (most of) the changes I think it
> > > needs (attached).  These changes are pleasantly minor, mostly just
> > > adding some example text and a bit of formatting.
> > >
> > > However.  Trying to actually use the information on this page is 
> > > turning
> > > up some problems.
> > I think the fundamental problem here is we ought not be exposing those
> > modifiers to the user.  They're inherently tied to the details of the
> > register allocation and reloading passes.
>
> This is what I'm thinking as well. 

I agree.

The only reason I didn't delete them before is that removing support for 
an existing feature can be contentious.  But I see no practical way to 
doc this for compiler-users.  And even as an inline-asm aficionado, I 
can't think of any use for them anyway.  Since there seems to be 
consensus, they're gone.

> Why would a user even need multi-alternative constraints in inline 
> asm?  An insn template might be instantiated in many different 
> contexts and need to deal with different flavors of operands, but 
> inline asm code is generally unique and the programmer writing it 
> knows very well what the operands are supposed to be (this one is a 
> register, that one is an address, etc).

I wouldn't go that far.  There are libraries that use inline asm 
(sometimes in headers), and a library cannot know how it may be used.  
The only practical approach for them is to list all options so gcc can 
do its best.

> Choosing the most efficient form of a logical-or instruction is hardly 
> a good motivating example, either -- nobody writes inline asm to do that.

However, it does make a good example for machine definitions, which also 
@includes this file.  And while perhaps not an optimal sample for inline 
asm, it is a reasonable one, since other platforms (including x86) have 
a similar instruction which has similar limitations.

> I'm under the impression that the primary uses of inline asm are 
> either to access machine instructions not exposed by builtins, or to 
> provide a block of highly tuned code replacing all/most of a C 
> function body.

I have attached a new patch.  It removes the flags and the paragraph 
that tries to describe how the alternative is chosen from the non-md 
docs.  Now it just says the compiler will choose the most efficient 
alternative.

Other than the line about "All operands for a single instruction must 
have the same number of alternatives", the 'internals' docs (which also 
includes this file) should be unaffected.

dw

Current text: https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html
Proposed text: http://limegreensocks.com/gcc/Multi_002dAlternative.html

Index: md.texi
===================================================================
--- md.texi	(revision 229470)
+++ md.texi	(working copy)
@@ -1465,6 +1465,8 @@
 constraint for an operand is made from the letters for this operand
 from the first alternative, a comma, the letters for this operand from
 the second alternative, a comma, and so on until the last alternative.
+All operands for a single instruction must have the same number of 
+alternatives.
 @ifset INTERNALS
 Here is how it is done for fullword logical-or on the 68000:
 
@@ -1482,9 +1484,7 @@
 @samp{0} for operand 1, and @samp{dmKs} for operand 2.  The @samp{=} and
 @samp{%} in the constraints apply to all the alternatives; their
 meaning is explained in the next section (@pxref{Class Preferences}).
-@end ifset
 
-@c FIXME Is this ? and ! stuff of use in asm()?  If not, hide unless INTERNAL
 If all the operands fit any one alternative, the instruction is valid.
 Otherwise, for each alternative, the compiler counts how many instructions
 must be added to copy the operands so that that alternative applies.
@@ -1521,7 +1521,6 @@
 the alternative only if the operand with the @samp{$} needs a reload.
 @end table
 
-@ifset INTERNALS
 When an insn pattern has multiple alternatives in its constraints, often
 the appearance of the assembler code is determined mostly by which
 alternative was matched.  When this is so, the C code for writing the
@@ -1529,7 +1528,22 @@
 the ordinal number of the alternative that was actually satisfied (0 for
 the first, 1 for the second alternative, etc.).  @xref{Output Statement}.
 @end ifset
+@ifclear INTERNALS
 
+So the first alternative for the 68000's logical-or could be written as 
+@code{"+m" (output) : "ir" (input)}.  The second could be @code{"+r" 
+(output): "irm" (input)}.  However, the fact that two memory locations 
+cannot be used in a single instruction prevents simply using @code{"+rm" 
+(output) : "irm" (input)}.  Using multi-alternatives, this might be 
+written as @code{"+m,r" (output) : "ir,irm" (input)}.  This describes
+all the available alternatives to the compiler, allowing it to choose 
+the most efficient one for the current conditions.
+
+There is no way within the template to determine which alternative was 
+chosen.  However you may be able to wrap your @code{asm} statements with 
+builtins such as @code{__builtin_constant_p} to achieve the desired results.
+@end ifclear
+
 @ifset INTERNALS
 @node Class Preferences
 @subsection Register Class Preferences