This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Add hardware build attributes in assembler
ClosedPublic

Authored by olista01 on Apr 7 2017, 9:36 AM.

Details

Summary

In the assembler, we should emit build attributes based on the target
selected with command-line options. This matches the GNU assembler's
behaviour. We only do this for build attributes which describe the
hardware that is expected to be available, not the ones that describe
ABI compatibility.

This is done by moving some of the attribute emission code to
ARMTargetStreamer, so that it can be shared between the assembly and
code-generation code paths. Since the assembler only creates a
MCSubtargetInfo, not an ARMSubtarget, the code had to be changed to
check raw features, and not use the convenience functions in
ARMSubtarget.

If different attributes are later specified using the .eabi_attribute
directive, then they will take precedence, as happens when the same
.eabi_attribute is specified twice.

This must be enabled by an option, because we don't want to do this when
parsing inline assembly. The attributes would match the ones emitted at
the start of the file, so wouldn't actually change the emitted object
file, but the extra directives would be added to every inline assembly
block when emitting assembly, which we'd like to avoid.

The majority of the changes in the build-attributes.ll test are just
re-ordering the directives, because the hardware attributes are now
emitted before the ABI ones. However, I did fix one bug which I spotted:
Tag_CPU_arch_profile was not being emitted for v6M.

Diff Detail

Repository
rL LLVM

Event Timeline

olista01 created this revision.Apr 7 2017, 9:36 AM
rengolin added inline comments.Apr 18 2017, 3:08 AM
lib/Target/ARM/AsmParser/ARMAsmParser.cpp
71

Why is this false? Don't we always want to emit the attributes?

olista01 added inline comments.Apr 18 2017, 3:20 AM
lib/Target/ARM/AsmParser/ARMAsmParser.cpp
71

We do want to emit attributes here when assembling an assembly file, but not when parsing inline assembly, so there's no obvious default when using this as part of clang. It's also not important what the default is when driving this from clang, as it doesn't change the final user interface.

When using this as a development/testing tool through llvm-mc, not emitting the build attributes is a sensible default, as you generally don't care about them, so I set this to default to false.

rengolin accepted this revision.Apr 18 2017, 4:25 AM

Makes sense. LGTM. Thanks!

This revision is now accepted and ready to land.Apr 18 2017, 4:25 AM
This revision was automatically updated to reflect the committed changes.