This is an archive of the discontinued LLVM Phabricator instance.

[ARM] [Assembler] Extend immediate conversions for A32, T32 and T16
ClosedPublic

Authored by sanwou01 on Mar 3 2017, 5:47 AM.

Details

Summary

Immediate converions change an instruction that cannot be encoded to an
equivalent but different instruction. For example, "ADD r0, r1, #FFFFFFFF"
cannot be encoded as an ADD instruction. However, "SUB r0, r1, #1" is
equivalent.

These conversions are different from instruction aliases. An alias maps
several assembler instructions onto one encoding. An immediate
conversion, however, maps an *invalid* instruction--e.g. with an
immediate that cannot be represented in the encoding--to a different
(but equivalent) instruction.

Several instruction immediates were being converted already, but this
was not systematically tested, nor did it cover the full set of possible
conversions.

This patch implements all possible substitutions for ARM, Thumb1 and
Thumb2 assembler and adds tests. It also adds a feature flag
(-mattr=+no-imm-conversions) to turn these substitutions off. This is
helpful for users who want their code to assemble to exactly what they
wrote.

Diff Detail

Repository
rL LLVM

Event Timeline

sanwou01 created this revision.Mar 3 2017, 5:47 AM
javed.absar edited edge metadata.Mar 4 2017, 11:28 AM

Hi Sanne:
Thanks for the patch. Please find some comments inline.
Best Regards
Javed

lib/Target/ARM/ARM.td
264 ↗(On Diff #90466)

If the substitution is only for instructions with immediates, would a narrower name e.g. FeatureNoImplicitImmSubstitution be more appropriate?

lib/Target/ARM/ARMInstrThumb.td
1244 ↗(On Diff #90466)

should this be imm3 instead?

test/MC/ARM/implicit-substitutions.s
116 ↗(On Diff #90466)

You may consider shortening this test by reducing 'CHECK-DISABLED: error: instruction requires ...' specially if there are duplication. Related question - is the feature flag just for testing?

sanwou01 updated this revision to Diff 90995.Mar 8 2017, 4:12 AM

Update in response to reviewer comments.

sanwou01 retitled this revision from [ARM] [Assembler] Extend implicit substitutions to [ARM] [Assembler] Extend immediate conversions for A32, T32 and T16.Mar 8 2017, 4:15 AM
sanwou01 edited the summary of this revision. (Show Details)
sanwou01 marked 2 inline comments as done.Mar 8 2017, 4:29 AM

Hi Javed,

Thanks for the review. I have updated the naming to use "immediate conversions" throughout. I think this is a better name, thanks for pointing it out.

See further comments inline.
Thanks,
Sanne

lib/Target/ARM/ARMInstrThumb.td
1244 ↗(On Diff #90466)

I don't think so? $imm is just a name here: the allowed range that is is controlled by the mod_imm1_7_neg below.

test/MC/ARM/implicit-substitutions.s
116 ↗(On Diff #90466)

The repetition of "error: instruction requires: ImmediateConversions" is necessary to test that -mattr=+no-imm-conversions properly disables all conversions.

No, the feature flag is not just for testing. The flag is helpful for users who want their code to assemble to exactly what they wrote. I have added this justification to the commit message.

rengolin edited edge metadata.

Hi Sanne,

We already had some ADD/SUB substitutions in the assembler, so if this is a more general approach, it should be encouraged, but we need to make sure we remove the old hack in favour of this patch.

Related patches:
http://llvm.org/viewvc/llvm-project?view=revision&revision=212722
http://llvm.org/viewvc/llvm-project?view=revision&revision=241166

cheers,
--renato

rengolin added a subscriber: aadg.Mar 8 2017, 7:00 AM

Hi Renato,

Thank you for the references. I hadn't looked at Aarch64 yet, but looking through those patches quickly, it looks like all conversions for negative immediates are already supported. It looks like it is using the same aliasing mechanism that I'm using. Changing Aarch64 to use InstSubst instead of InstAlias should make sure that -mattr=+no-imm-conversions works for Aarch64 too.

That said, maybe NegativeImmediates/no-neg-immediates is an even better name for this feature!

Thanks,
Sanne

Right, I just compared this patch to the two I linked earlier and it seems this patch is a lot cleaner than the ones we had before for AArch64.

If @javed.absar is happy with it, so am I.

cheers,
--renato

javed.absar accepted this revision.Mar 14 2017, 7:04 AM

Thanks Sanne and Renato.
LGTM to me as well.

This revision is now accepted and ready to land.Mar 14 2017, 7:04 AM
This revision was automatically updated to reflect the committed changes.