This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Allow Half types in ConstantPool
ClosedPublic

Authored by SjoerdMeijer on Feb 1 2018, 1:04 AM.

Details

Summary

Change ARMConstantIslandPass to:

  1. accept f16 literals as litpool entries,
  2. if the litpool needs to be inserted in the middle of a big block, then we need to 4-byte align the next instruction in ARM mode.

Diff Detail

Repository
rL LLVM

Event Timeline

SjoerdMeijer created this revision.Feb 1 2018, 1:04 AM
SjoerdMeijer edited the summary of this revision. (Show Details)
olista01 added inline comments.Feb 9 2018, 7:07 AM
lib/Target/ARM/ARMConstantIslandPass.cpp
513 ↗(On Diff #133611)

Is this assertion still useful?

1432 ↗(On Diff #133611)

It looks like this function is called when a BB must be split to insert a constant island, but not when extending an existing one. Will this fail if a BB is split to insert a 32-bit constant, and that island is then extended with a 16-bit constant?

Why is this being done for Thumb2?

Would it be easier to always setting the alignment of the new block to 1 for Thumb and 2 for ARM, so that this will work if we add 1-byte literal pools in future? I think that should also fix the issue of extending existing islands too.

Removed the assert, and thanks for the suggestion: I think it is
indeed the easiest and best to always set the alignment.

olista01 added inline comments.Feb 12 2018, 1:54 AM
lib/Target/ARM/ARMConstantIslandPass.cpp
1432 ↗(On Diff #133611)

This is still only going to be triggered if the _first_ entry in the constant pool is 2-byte, I think it will fail if the first entry is 4-byte, and the last is 2-byte. Would it also be possible to add a test for this case?

SjoerdMeijer updated this revision to Diff 133865.EditedFeb 12 2018, 7:58 AM

It was indeed failing when there e.g. was an existing 4-byte entry, which was
then followed by a 2-byte entry; the two new ARM and Thumb test cases
showed this. As suggested, we are now always emitting an alignment directive
(I've removed that if-statement).

The Thumb test case was running in an assert related to addressing modes.
I've created D43179 for that, which I need for this patch.

olista01 added inline comments.Feb 12 2018, 9:58 AM
test/CodeGen/ARM/fp16-litpool.ll
47 ↗(On Diff #133865)

There are more literal pools here than needed for the test, because the addresses of the globals are materialised as literal pools too. Could this be simplified by passing them in as arguments?

This whole test file is also fragile, as it depends on decisions made by other parts of the backend about whether to use literal pools, and the exact ordering of instructions when we get to the constant pool placement pass. It would be better to convert this to an MIR test to avoid that.

Thanks for the suggestions.
I've created MIR tests (and simplified the test case a little bit more).

olista01 accepted this revision.Feb 13 2018, 7:28 AM

LGTM, thanks

This revision is now accepted and ready to land.Feb 13 2018, 7:28 AM
This revision was automatically updated to reflect the committed changes.