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

[Eric Christopher]

On Wed, Mar 13, 2013 at 1:04 PM, Måns Rullgård <mans at mansr.com> wrote:

> Jim Grosbach <grosbach at apple.com> writes:
>
> > On Mar 13, 2013, at 11:21 AM, Måns Rullgård <mans at mansr.com> wrote:
> >
> >> Jim Grosbach <grosbach at apple.com> writes:
> >>
> >>> On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at linaro.org>
> >>> wrote:
> >>>
> >>>> On 13 March 2013 17:57, Jim Grosbach <grosbach at apple.com> wrote:
> >>>>> 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.
> >>>> This is correct.
> >>>>
> >>>> Ok, so maybe checking all possible ways to require paired registers
> >>>> is not such a bad idea after all.
> >>>>
> >>>
> >>> The constraints are the right way to do it. There shouldn't be any
> >>> magic beyond that.
> >>
> >> Since there is no special operand constraint for a register pair, there
> >> is no way to tell at that level.
> >>
> >> GCC has (implicitly) defined 64-bit register operands as residing in
> >> even/odd pairs, thus leaving inline asm free to make all manner of
> >> assumptions based on this.  The only way I see to guarantee
> >> compatibility is to mimic the gcc behaviour here.  It may be slightly
> >> suboptimal in a few cases, but it's the safe choice.
> >
> > Sure, that's fine for ARM mode. No realistic other option there. So
> > long as Thumb2 code can get the more expressive syntax for the more
> > relaxed regalloc availability, it's all good. This basically falls
> > into "using the constraints to figure it out."
>
> So let's at least make this pair allocation unconditional in ARM mode.
> A lot of existing inline asm doesn't work in Thumb mode anyway, so if
> that fails, it's less of an issue.
>
>
I can agree with this. Bugged me last time I was looking at it too.

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