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

[Weiming Zhao]

Hi Renato,

 

It seems to me that LLVM doesn’t parse the inline asm body. It just checks
the constraints, (ie. Input/output interface). During ASM writing, it then
binding those constraints to placeholders like %0, %1.  

So it a constraint is a 64-integer type, it *probably* needs paired GPR.

 

Weiming

 

 

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

 

From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: Wednesday, March 13, 2013 10:03 AM
To: Måns Rullgård
Cc: LLVM Dev; weimingz at codeaurora.org
Subject: Re: Problems with 64-bit register operands of inline asm on ARM

 

On 13 March 2013 13:43, Måns Rullgård <mans at mansr.com> wrote:

One possible fix, which I have tested, is to look for the specific
instructions requiring such a pair (LDRD/STRD and LDREXD/STREXD) in
addition to the 'H' modifier.  However, there are probably other
creative ways in which inline asm might rely on the specific pairing.

 

Hi Mans,

 

Either that method is ignoring an inline asm parser or there isn't one, but
I agree, we should be able to have something better than just grep for
possible extensions for paired registers.

 

 

Thus I believe the safest solution is to always force 64-bit operands
into even/odd pairs for any inline asm.  In other words, we should
probably do something like this (untested):

 

I tested this, and it fails on other inline assembly tests. I think that the
non-paired asm is correctly selected by the table generated parser, but when
you pair things that didn't need pairing, the parser goes bad.

 

I don't think we should force pairing on every inline assembly either. Maybe
someone knows how to parse inline assembly in a better way than it is
currently being done? If there isn't any, than possibly creating a function
to return "needsPairedRegister()" or something would still be ugly, but
better than incrementing it inline.

 

cheers,

--renato

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/b2e7d2a3/attachment.html>