inline asm and multi-alternative constraints

[David Wohlferd]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ma3.patch
Type: text/x-patch
Size: 2522 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20151103/fbac14b3/attachment.bin>