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

[Weiming Zhao]

Hi Måns,

If you try my patch, it supports "ldrd %0, [%1]" although my test case
doesn't include that.

The current logic is, for inline asm, LLVM just emits one reg for %x place
holders. 
For a GPRPair, when it sees %0, it emits the first sub reg.
When it sees %H0, it emits the second sub reg.
On the other side, it's hard for LLVM to give a warning diagnose for your
test because LLVM doesn’t even parse the instruction string inside the
inline asm.

Thanks,
Weiming
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation


-----Original Message-----
From: Måns Rullgård [mailto:mans at mansr.com] 
Sent: Wednesday, March 27, 2013 5:22 PM
To: Jim Grosbach
Cc: Måns Rullgård; weimingz at codeaurora.org; Renato Golin; Kristof Beyls;
Eric Christopher; Jakob Stoklund Olesen; LLVM Commits
Subject: Re: [LLVMdev] Problems with 64-bit register operands of inline asm
on ARM

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