[LLVMdev] Problems with 64-bit register operands of inline asm on ARM

Måns Rullgård mans at mansr.com
Wed Mar 27 17:21:46 PDT 2013


Jim Grosbach <grosbach at apple.com> writes:

> On Mar 27, 2013, at 4:57 PM, Måns Rullgård <mans at mansr.com> wrote:
>
>> Jim Grosbach <grosbach at apple.com> writes:
>> 
>>> On Mar 27, 2013, at 2:38 PM, Weiming Zhao <weimingz at codeaurora.org> wrote:
>>> 
>>>> Hi Måns
>>>> 
>>>> Oh, so you mean GAS will implicitly add a reg even if only one reg is
>>>> specified in assembly. Right?
>>> 
>>> Both registers are required in the syntax. GAS is more lenient, but is
>>> in error. We don't need to follow their bad example here.
>> 
>> GAS is not *wrong*, strictly speaking.  It is not forbidden for an
>> assembler to accept syntax beyond that described in the ARM ARM.  In
>> fact, this is even encouraged in some places.
>> 
>> Since this syntax is non-standard, you are correct that there is no
>> _need_ to follow this.  However, if the aim is for clang/llvm to compile
>> existing source code unmodified, this does become a requirement, like it
>> or not.
>
> We want to do the right thing, not blindly accept whatever language
> extensions other toolchains have adopted. Sometimes that means telling
> people they need to modify their source code to conform to our
> stricter adherence to documentation. This is one of those places. This
> syntax is a relic of the old divided syntax, which LLVM's assembler
> does not support. We should be actively deprecating what support there
> is for divided syntax (i.e., adding warnings when it's used, then
> removing it entirely in following releases), not expanding support for
> it.

That approach may work for a closed outfit like Apple.  In the open
world, all it will accomplish is further cementing the dominance of
gcc.  If strict conformance to standards is more important to you than
uptake of your product, fine with me.  Just don't expect developers to
be falling over themselves to adapt to your stricter requirements when
gcc, in their eyes, works perfectly well.

Besides, clang/llvm already supports a large number of gcc extensions.
Who decides, and how, which ones are accepted and which get short
shrift?

-- 
Måns Rullgård
mans at mansr.com




More information about the llvm-commits mailing list