This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Implement eabi_attribute, cpu, and fpu directives.
ClosedPublic

Authored by logan on Oct 21 2013, 8:43 AM.

Details

Summary

This commit adds the eabi_attribute, cpu, and fpu directives
support to the ARM assembly parser. Besides, this commit
also moves switchVendor(), emitAttribute(),
emitTextAttribute(), emitFPU() to ARMTargetStreamer.

It has been verified that the output binaries of the changed
test case remain unchanged.

Diff Detail

Event Timeline

Overall, it looks like a good move. Apart from my other comments, I think it's good. I'd love to get Richard Barton to review this code, as he's an ace in spotting architecture mismatches. I'll include him in the reviewers' list.

lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
138

A better name for this would be CPU

179

I don't think so.

493

These two functions look redundant. Is it just in ARM's case?

495

It'd be really good to get rid of string parsing at this level...

Er, I can't. Logan, can you add Richard as the reviewer, please?

logan added inline comments.Oct 22 2013, 8:46 AM
lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
138

For now, this function is only for CPU. I am fine to rename this function. However, I am not sure whether it is a good idea or not. According to the specification, there might be other text attributes, such as Tag_CPU_raw_name, Tag_CPU_name, Tag_compatibility, Tag_also_compatible_with, and Tag_conformance. I can do the work if you feel that emitCPU() is better.

179

This function is copied from AttrEmitter (including the comment). I think we can leave this function unchanged for now. I am planning to move getULEB128Size() from MCAsmInfo to llvm/Support/LEB128.h, and remove this function in the future.

493

Sorry. I don't understand what do you mean by redundant. These are virtual functions used by the AsmPrinter and AsmParser. May you further describe your question? Thanks.

495

OK. Will be updated in next revision of this patch.

logan updated this revision to Unknown Object (????).Oct 22 2013, 11:08 AM
  • Avoid string parsing in emitFPU().
  • If there are multiple .fpu directive, then the later should overwrite the former one.

Thanks Logan, looks a lot better. I'm happy when Richard is happy.

lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
138

Oh, my bad, ignore.

179

Agree.

493

It might just be my lack of contact with this code for a while, but this looks like it's just adding two aliases to the overloaded "setAttributeItem" function.

My question was related to the need to have this extra level of indirection if they're just calling another function, or if it was better to, either expose the other two, or rename them to "emitAttribute" and "emitTextAttribute".

This may not be the case with other back-ends, so I'm not sure my question is at all relevant.

Thanks a lot for this patch!

I have just one small question, but it looks fine from a MC organization point of view in any case. Please just wait for a LGTM from someone with more ARM experience.

Hi Logan

I have a few reservations about the behaviour of the .fpu vs .eabi directives generation which are in the comments.

Also would like to see a few more tests added, just to get full coverage. If you can show these cores/architecture configurations are covered by other testing elsewhere then that would be fine too.

Otherwise, looks great. Thanks for the patch.

Rich

test/CodeGen/ARM/2010-09-29-mc-asm-header-test.ll
81

I understand that we are choosing not to emit the .eabi_attribute directive for Tag_FP_arch in favour of the .fpu directive because that's what GNU does, but we are also emitting the .eabi_attribute directive for Tag_Advanced_SIMD_arch at the same time. Is this just to be compatible with GNU as well?

96

This is inconsistent with above when the .eabi_attribute directive for Tag_Advanced_SIMD_arch was left in. Which is right? Or is this just being compatible with GNU again?

test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll
2–32

It would be nice to get full coverage of the FPU options that you have touched, so:

  • R4 - VFPv3_D16
  • M4F AKA M4 - VFPv4_D16 (and also v7E-M)
  • A15 - VFPv4+NEONv2 (and also without neon)

For the half-precision only variants, there is another build attribute that needs setting: Tag_VFP_HP_extension, but I accept that is beyond the original scope of this patch, so the test strings are ok without it for now.

17

This is a duplicate of line 9 above.

20

This test generates identical attributes to line 7 above. It would be nice to see a test for a v7 core with VFPv4, so Cortex-A15.

33–34

typo in comment

Hi Logan,

I have similar questions as Richard about the FP_arch emission. Once you address the other points, this patch looks ok to me.

Amara

test/CodeGen/ARM/2010-09-29-mc-asm-header-test.ll
37

I'm still unsure about removing these, but won't block the patch over it.

logan added inline comments.Oct 25 2013, 9:28 AM
lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
493

To make the code cleaner, I have slightly change this to:

setAttributeItem(Attribute, Value, /* OverwriteExisting= */ true);

So that it will be clear that this is not a simple delegation. BTW, I wrote setAttributeItem() because I wish to ignore the eabi_attribute request if it has been emitted. IMO, it is not a good idea to add more argument to emitAttibute(), because the OverwriteExisting option is meaningless to the ARMTargetAsmStreamer. Hoping this can answer your question.

logan added inline comments.Oct 25 2013, 10:07 AM
lib/Target/ARM/ARMAsmPrinter.cpp
663–673

The special case which we keep emitting Tag_Advanced_SIMD_arch.

669

After further testing, it seems that we have to use Subtarget->hasD16() instead. However, I am not sure why was the old code using Subtarget->isFPOnlySP(). I will change this in next revision. Any thoughts?

test/CodeGen/ARM/2010-09-29-mc-asm-header-test.ll
81

I am removing most of the Tag_Advanced_SIMD_arch. However, the following case can't be mapped to a single .fpu directive.

; RUN: llc < %s -mtriple=armv8-linux-gnueabi -mattr=-fp-armv8,-crypto | FileCheck %s --check-prefix=V8-NEON

That's why you still can see a special case in ARMAsmPrinter.cpp (Line:663)

test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll
2–32

Both cortex-m4 and cortex-a15 will be added to next revision of this patch. However, it seems that LLVM can't recognize cortex-r4 as the mcpu option. I will use cortex-r5 instead (p.s. According to the result, it seems that R5 is using VFPv3_D16 as well)

17

Thanks. Will be removed. I haven't notice this when I was copy the test command from 2010-09-29-mc-asm-header-test.ll.

20

Thanks. Test for Cortex-A15 will be added in next revision of this patch.

33–34

Thanks. Will be fixed in next revision.

lib/Target/ARM/ARMAsmPrinter.cpp
669

Yep - that is a bad miss on my part. I fear I've been guilty of being sloppy with my language in comments which might have caused confusion also.

The ..._D16 VFP architectures, single-precision only VFP architectures and half-precision are three distinct things.

VFPv3_D16 and VFPv4_D16 just means that there are half the number of FP registers available, both double- and single-precision (and sometimes half-preicions) VFP is available. These properties manifest in the Tag_FP_arch attribute.

Half-precision FP is an optional extension to VFPv3 and part of the base VFPv4 architecture. This property manifests in the Tag_FP_HP_extension attribute.

Single-precision-only FP is available for VFP architectures from version 2 and up and is described by a Tag_ABI_HardFP_use attribute value of 1.

I guess that the old code was just plain wrong, thanks for catching this and setting it right.

This also highlights the importance of adding those R5 and M4 tests.

logan updated this revision to Unknown Object (????).Oct 26 2013, 2:13 AM

Add test cases for cortex-a15, cortex-m4, and cortex-r5 and fix hasD16().

This revision of patch has following change:

  • Remove the redundant armv7 and armv8 object file test case.
  • Add cortex-a15, cortex-m4, and cortex-r15 test case.
  • Fix typo in comments.
  • Change Subtarget->isFPOnlySP() to Subtarget->hasD16(). In order not to break the test, FeatureD16 are added to cortex-m4 and cortex-r5.
  • Remove the default value for OverwriteExisting in setAttributeItem().
logan added inline comments.Oct 26 2013, 2:32 AM
lib/Target/ARM/ARM.td
312

For not breaking the existing test cases, I have to add FeatureD16 to cortex-r5 subtarget. Although this is the default behavior of GCC, however, I can't find any document stating cortex-r5 has only d0-d15. Should I change the test case instead?

324–325

According to ARMv7-M Reference Manual, the ARM floating point extension for ARMv7-M is named as FPV4-SP, which is a single precision only variant of VFPv4-d16. Thus, I think we should add FeatureD16 to this subtarget.

Hi Logan

One last problem with the R5 definition that will require a test change and this patch is good to commit.

Thanks for contributing and for the adding all the extra testing to make sure its just right.

Rich

lib/Target/ARM/ARM.td
312

The TRM for Cortex-R5 shows this here http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1019986.html

So your patch is correct.

324–325

Absolutely correct.

test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll
258

One last problem - the R5 has been specified incorrectly and shouldn't support the ARM divide extension. So Tag_DIV_use should not be emitted, or emitted with value 0. I think just correcting the definition of R5 in ARM.td ought to just sort this out though.

logan updated this revision to Unknown Object (????).Oct 27 2013, 1:01 AM

Address the cortex-r5 ARM hardware division extension issue.

logan added inline comments.Oct 27 2013, 1:18 AM
test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll
258

Do you mean that R5 does not support ARM hardware division extension? Does cortex-r5 support Thumb2 hardware division? From the commit history, it seems that cortex-r5 should support Thumb2 hardware division. Thus, I didn't remove FeatureHWDiv from ProcR5.

I have removed FeatureHWDivARM from ProcR5 in new revision, however, the change breaks test/CodeGen/ARM/div.ll. It seems reasonable for me to change this test case to use soft-fp if cortex-r5 does not support ARM hardware division extension. Any comments?

Hi Logan, Rich,

If I'm reading the Cortex-R5 manual correctly, it should support both the arm and thumb hw division instructions
from r1p0 onwards (see http://infocenter.arm.com/help/topic/com.arm.doc.ddi0460d/DDI0460D_cortex_r5_r1p2_trm.pdf).

Therefore, I think R5 should still have the hw division extension (both for arm and thumb).

Thanks,
Silviu

logan updated this revision to Unknown Object (????).Oct 27 2013, 8:58 AM

Revert the FeatureHWDivARM change.

logan added a comment.Oct 27 2013, 9:10 AM

Hi Silviu,

Thanks for your comment. After reading Cortex-R5 TRM p.74, 106, and 439, I agree with you that R5 has hardware division for both ARM and Thumb. Richard, do you have different opinion or any further comments? Thanks.

Best regards,
Logan

Nope, I'm wrong again. Thanks Silviu.

logan added a comment.Oct 28 2013, 7:58 AM

Hi Richard and Renato,

Is it OK to commit this patch now? Thanks.

Logan

I'm happy - thanks for all your hard work.

Thanks. Committed as r193524.

logan accepted this revision.Oct 28 2013, 11:43 AM
logan closed this revision.