This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Create SubtargetFeatures from build attributes
ClosedPublic

Authored by samparker on Jan 4 2017, 5:53 AM.

Details

Summary

Currently, ELFObjectFile is used to build a SubtargetFeatures object for MIPS. I've moved the MIPS specific code into its own function and then also created an ARM specific function which builds the features from quering the build attributes. Together with D28281 it enables llvm-objdump to automatically create an accurate target.

Diff Detail

Repository
rL LLVM

Event Timeline

samparker updated this revision to Diff 83040.Jan 4 2017, 5:53 AM
samparker retitled this revision from to [ARM] Create SubtargetFeatures from build attributes.
samparker updated this object.
samparker added a subscriber: llvm-commits.

Also, please add negative tests, to make sure that we still refuse support when no attributes are found, or when those that are found restrict the target.

test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

If you pass the -mattr, it doesn't need to read the .eabi_attributes, so what does this test really test?

samparker added inline comments.Jan 12 2017, 5:44 AM
test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

As far as I can tell, the mattr is used by mc to detect valid instructions, but it is not used to encode the build attributes. So they're needed in the test so the attributes are encoded for objdump to read.

rengolin added inline comments.Jan 12 2017, 7:25 AM
test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

That's my point. Here you have two ways to setup the attributes: -marttr and .eabi_attribute. What you need is to make sure that *both* ways work for your purposes.

If you create one test with -mattr and *another* with the same .eabi_attribute, making sure they're complete to describe what you need, than you covered both cases.

samparker added inline comments.Jan 12 2017, 7:45 AM
test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

But this patch isn't about enabling llvm-mc to write attributes that are provided via the -mattr option. These tests surely only need to prove that they can use what is provided in the binary.

rengolin added inline comments.Jan 12 2017, 11:47 AM
test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

Then I don't understand what the patch is about. ;)

What I see is an patch that reads the build attributes (not the -mattr) and adds those features to the target's list.

If you add the same attributes via -mattr, then reading the attributes will make no difference, ie. the test will pass without the build attributes being present.

To make sure the build attributes parsing and feature-setting behaviour works, you should *not* have those attributes already there (via -mattr) and let the build attributes be parsed, add the features and see if it works.

what am I missing here?

samparker added inline comments.Jan 13 2017, 1:30 AM
test/tools/llvm-objdump/ARM/v7a-subfeature.s
1 ↗(On Diff #83040)

Ok. So the -mattr is required to enable llvm-mc to assemble the instructions because llvm-mc does not use the assembler directives to create a target for itself.

So if I remove +hwdiv-arm for an armv7a target, llvm-mc will fail to encode the instruction even if there is an assembler directive. I need to use -mattr to create a valid target for llvm-mc and I need the assembler directives so that llvm-mc encodes the build attributes into the its output.

samparker updated this revision to Diff 84259.Jan 13 2017, 1:49 AM

Features can now also be disabled to override possible architecture defaults and I've also enabled +hwdiv for M and R class armv7 architectures. Added some negative tests too.

rengolin accepted this revision.Jan 13 2017, 3:08 AM
rengolin added a reviewer: rengolin.

Right, with the negative tests, it makes more sense now. Also, good split on the getFeatures. LGTM. Thanks!

This revision is now accepted and ready to land.Jan 13 2017, 3:08 AM
This revision was automatically updated to reflect the committed changes.
echristo added inline comments.
llvm/trunk/include/llvm/Object/ObjectFile.h
270

Possibly should just be an internal helper routine and not a virtual alongside the normal API?