inline asm and multi-alternative constraints

[Jeff Law]

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.

> First, it could use a bit more clarity in the text that describes how
> gcc chooses among the alternatives.  There are apparently 3 criteria
> that affect this decision: # of statements needed to copy params, order
> of alternatives, and flags.  But it appears that they aren't all
> weighted equally.  For example no number of '?' seem to be able to
> override an alternative that causes a reload (change the example below
> to use eax instead of ebx).  But before I try to re-phrase this
> paragraph, I'm hoping someone can provide more details.  What exactly
> are the rules here?
Probably more complex than anyone could put in a couple pages of text. 
You're in the realm of some of the most complex code in GCC.


>
> Second, attempting to use ! and $ isn't working the way the docs led me
> to expect (actually, I can't make them work at all).  Starting with this
> (contrived) i386 code, gcc selects the second alternative (using -O2 for
> x64).  This makes sense to me.
?? is not the same as !

In fact, no documented number of ?s are equivalent to a !.  More than 
one ! is meaningless.

A "reload" has a very specific meaning and unless someone is intimately 
familiar with the inner workings of GCC a definition of a reload isn't 
going to make any sense.  Worse yet, some ports don't use "reload" 
anymore, but the new code still supports ? and ! to some degree for 
compatibility's sake.

We ought to bury those modifiers into the developer manual and avoid 
them in the user manual completely.

jeff