llvm dev - Nov 2013 - [LLVMdev] Implementing the ldr pseudo instruction in ARM integrated assembler

Hi Tim,
> > 8. Check that an error is issued when the constant pool would be
> > placed too far away
> 
> I'd say this one is actually the most involved constraint but there
don't
> actually seem to be any tests in the attached file for it.
I put the test in a separate file and forgot to attach it earlier. I've
attached it to this email. I can't say how difficult this will be to
implement, but Jim also indicated it could be tricky so I believe you both
:). I only have a simple test for this now, but I'd welcome suggestions on
improving it or any hits on the implementation.

> And I believe the directive Jim's referring to is ".ltorg".
It's
> presumably going to have some interesting quirks of its own.
Yes, I replied to Jim saying that I was planning to implement .ltorg in a
separate step.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldr_pseudo_errors.s
Type: application/octet-stream
Size: 17617 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/2215fd20/attachment.obj>

> I put the test in a separate file and forgot to attach it earlier. I've
> attached it to this email.
The ".space" directive could be very useful in making the test more
manageable.

Other than that I'd be wary of instructions that might be relaxed
during object emission and suddenly make a load out of range. LLVM
seems to do this for Bcc, pc-relative loads, ADR and B. It's getting
towards implementation details but you'll want to bear it in mind when
adding tests for any implementation.

One question that's occurred is can this support PIC when you
reference other sections? That may well affect the relocation used.

ARM's own assembler may be able to (it certainly has --apcs=...
options that can tell it it's compiling PIC code). I can't recall a
similar command-line option to llvm-mc, but Clang-as-assembler
probably accepts -fPIC.

Goodness knows whether we want to do anything with it though.

(from Jim)
> What does ARM’s documentation say?
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/Bgbbfgia.html

Fairly similar, though it doesn't seem to use a MOV opportunistically.

Tim.

> The ".space" directive could be very useful in making the test
more
> manageable.
Ah, yes that is a great suggestion. Thank you!
> Other than that I'd be wary of instructions that might be relaxed
during
> object emission and suddenly make a load out of range. LLVM seems to do
> this for Bcc, pc-relative loads, ADR and B. It's getting towards
> implementation details but you'll want to bear it in mind when adding
> tests for any implementation.
Ok, thanks I will keep that in mind. Sounds like it could be tricky to write
a test for it, but I will try.
> One question that's occurred is can this support PIC when you reference
> other sections? That may well affect the relocation used.
> 
> ARM's own assembler may be able to (it certainly has --apcs=...
> options that can tell it it's compiling PIC code). I can't recall a
> similar command-line option to llvm-mc, but Clang-as-assembler probably
> accepts -fPIC.
> 
> Goodness knows whether we want to do anything with it though.
Hmm, yes I had not considered that. It's a good question.
> (from Jim)
> > What does ARM's documentation say?
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/Bgbbf
> gia.html
> 
> Fairly similar, though it doesn't seem to use a MOV opportunistically.
I did notice the use of movw by armasm when comparing to gcc. I never did
observe gcc using movw and I was planning to follow that for the first step.
I think using movw would be a useful follow-on optimization.