This is the mail archive of the
mailing list for the GCC project.
Re: inline asm and multi-alternative constraints
- From: Jeff Law <law at redhat dot com>
- To: David Wohlferd <dw at LimeGreenSocks dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, pinskia at gcc dot gnu dot org, rearnsha at gcc dot gnu dot org
- Date: Mon, 9 Nov 2015 14:52:25 -0700
- Subject: Re: inline asm and multi-alternative constraints
- Authentication-results: sourceware.org; auth=none
- References: <562DA0E2 dot 1040405 at LimeGreenSocks dot com> <562FE71E dot 7010309 at redhat dot com> <563285D8 dot 6020001 at redhat dot com> <563430F8 dot 7020406 at LimeGreenSocks dot com> <5637EC6F dot 7020505 at redhat dot com> <5637F50A dot 1090002 at codesourcery dot com> <56385495 dot 1050507 at LimeGreenSocks dot com> <563D29D7 dot 9000707 at redhat dot com> <20151107004639 dot GA27264 at gate dot crashing dot org> <563DAD50 dot 1010701 at LimeGreenSocks dot com>
On 11/07/2015 12:50 AM, David Wohlferd wrote:
Right. =+& are no-brainer yes, as are the constants 0-9. % is probably
OK as well.
- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm. But both "#*" seem sketchy.
#* are similar to !? in that they are inherently tied into the register
class preferencing implementation and documenting them would be inadvisable.
The various offsettables (oV), pre/post increment (<>), address (p) make
sense I'm not sure about (s).
- Under 'simple constraints', "mringX" all (more or less) make sense to
me. But "oV<>sp" are not things I can envision using.
- The 'machine constraints' for i386 (the only machine I know) all seem
reasonable. However for platforms that support autoincrement
(powerpc?), apparently using "m" needs more docs (per
A few may be md-only, but generally folks have found that getting access
to the target's constraints to be useful in asms. I was hesitant to
document them initially because it made it much easier for someone to
setup a situation where the compiler couldn't generate correct code.
Those issues have (mostly) been fixed through the years.
Are these the things to which you are referring? I've always assumed
the parts that seem obscure here were due to my i386-centric view of the
world. Are some of them actually md-only?