inline asm and multi-alternative constraints

[Jeff Law]

On 11/02/2015 11:30 PM, David Wohlferd wrote:
>>> 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.
It's never easy to predict whether or not something like this will be 
contentious.  Worst case is you post, it's contentious, we iterate a bit 
and reach some kind of resolution (ok, worst case is no resolution is 
reached, but that doesn't happen to often).

In this case I simply don't see a way to sensibly document those 
modifiers without bringing in the implementation details of register 
class preferencing, reload, IRA & LRA.  And once those details are 
brought into the picture, everyone loses.

I'm sure there's someone out there using '?' and '!' in a 
multi-alternative asm constraint.  They may even read the docs and 
complain and we can try to educate them why those modifiers are no 
longer documented.


>
>> 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.
It's a reasonable simple example which shows how one might use 
multi-alternative constraints in an asm.   It doesn't have to be 
real-world, it has to be understandable and extendable to something a 
user might want to do.  I think this example fits that reasonably well.


>
>> 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.
This looks fine.  I'll install it momentarily.

jeff