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.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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? |
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. |
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. |
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. |
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? |
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. |
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.
Right, with the negative tests, it makes more sense now. Also, good split on the getFeatures. LGTM. Thanks!
llvm/trunk/include/llvm/Object/ObjectFile.h | ||
---|---|---|
270 | Possibly should just be an internal helper routine and not a virtual alongside the normal API? |
Possibly should just be an internal helper routine and not a virtual alongside the normal API?