This is an archive of the discontinued LLVM Phabricator instance.

[ARM] LE support in ConstantIslands
ClosedPublic

Authored by samparker on Sep 10 2019, 9:05 AM.

Details

Summary

The low-overhead branch extension provides a loop-end 'LE' instruction that performs no decrement nor compare, it just jumps backwards. This patch modifies the constant islands pass to try to insert LE instructions in place of a Thumb2 conditional branch, instead of shrinking it. This only happens if a cmp can be converted to a cbn/z and used to exit the loop.

Diff Detail

Repository
rL LLVM

Event Timeline

samparker created this revision.Sep 10 2019, 9:05 AM

The piece, that I know, is missing is checking whether we're not creating nested LE loops - which we want to avoid.

Nice. I was expecting this to happen earlier, maybe in the other branch optimisations. This seems like a good place for it, though.

What does it do for codesize?

lib/Target/ARM/ARMConstantIslandPass.cpp
1935 ↗(On Diff #219555)

for (ImmBranch &Br : reverse(ImmBranches))

1986 ↗(On Diff #219555)

Can you explain this? Is it that we know that this is the LE case, and the other br at the end of the block is being deleted? Can you add a comment.

samparker marked an inline comment as done.Sep 13 2019, 1:12 AM
samparker added inline comments.
lib/Target/ARM/ARMConstantIslandPass.cpp
1986 ↗(On Diff #219555)

That's it. But now looking at it again, I'm not sure if Br.MI could actually be LastMI too...

As far as I can tell, code size will always be worse: instead of generating just a cbn?z, we also need the T2 LE instruction. I'll add a check and prevent the optimisation at minsize.

samparker updated this revision to Diff 220070.Sep 13 2019, 3:37 AM
  • Now allowing CBZ and CBNZ, had got myself a bit confused there...
  • Added comment.
  • Checking terminator before removing it.
  • Added more tests.

Thanks. You mentioned something about nested loops. Is that still an issue?

I'd say that it's sub-optimal... I don't know how often the issue will arise and whether that justifies using LoopInfo here. I'm also unsure how that extra logic would fit in with the current optimisation as we'd want to visit inner loops first, instead of walking backwards.

dmgreen accepted this revision.Sep 17 2019, 1:56 AM

I'd say that it's sub-optimal... I don't know how often the issue will arise and whether that justifies using LoopInfo here. I'm also unsure how that extra logic would fit in with the current optimisation as we'd want to visit inner loops first, instead of walking backwards.

Yeah, I agree. I don't think it should cause too much trouble to have nested LE's, it would just invalidate the loop info on each outer iteration.

LGTM.

This revision is now accepted and ready to land.Sep 17 2019, 1:56 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 17 2019, 2:07 AM