This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Move the creation of VBICIMM and VORRIMM to lowering
AcceptedPublic

Authored by dmgreen on Jul 7 2021, 1:47 PM.

Details

Summary

These opcodes were being created as combines, meaning they can be created very early. This moves that so that they are created during lowering or the And/Or, meaning other target independent optimizations are more likely to fire, leading to better code.

Making Or and And custom does require some cost adjustments to keep the cost at 1. In the long run, I think it would be good to remove VMOVImm/VBICImm/VORRImm and recognize them during selection.

Diff Detail

Event Timeline

dmgreen created this revision.Jul 7 2021, 1:47 PM
dmgreen requested review of this revision.Jul 7 2021, 1:47 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 7 2021, 1:47 PM

If you just want to delay the combine, I'd suggest just adding a DCI.isAfterLegalizeDAG() to the existing DAGCombine. Doing it during lowering can lead to weird results; for example, AArch64 currently does this, and there's testcase where we end up with orr v0.2s, #0.

If you just want to delay the combine, I'd suggest just adding a DCI.isAfterLegalizeDAG() to the existing DAGCombine. Doing it during lowering can lead to weird results; for example, AArch64 currently does this, and there's testcase where we end up with orr v0.2s, #0.

The buildvectors will not be legal at that point, and the VBIC will be a different set of immediates to VMOVIMM. That was how I first attempted it. But I think I would prefer not to rewrite the transform if it will just be replaced in the future.

samtebbs accepted this revision.Aug 3 2021, 3:20 AM

LGTM

This revision is now accepted and ready to land.Aug 3 2021, 3:20 AM