This is an archive of the discontinued LLVM Phabricator instance.

[TypePromotionPass] Don't treat phi's as ToPromote
ClosedPublic

Authored by dmgreen on Sep 2 2022, 6:49 AM.

Details

Summary

This attempts to stop the type promotion pass transforming where it is not profitable, by not marking PhiNodes as ToPromote.

Diff Detail

Event Timeline

dmgreen created this revision.Sep 2 2022, 6:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 2 2022, 6:49 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
dmgreen requested review of this revision.Sep 2 2022, 6:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 2 2022, 6:49 AM

It's not clear to me, from the tests, why a phi shouldn't be considered profitable... having cmp w*, w*, uxt* in those atomic loops look slower to me. Maybe we should be checking whether the phi is in a loop or not?

The goal was to fix llvm/test/CodeGen/AArch64/typepromotion-cost.ll (or a larger version of it), where there is no loop here but I believe the larger version is part of a larger loop. The point is that PhiNodes should not be considered "ToPromote" in the current cost calculation. They don't benefit from being promoted on their own - it is the uses of them that benefit.

The atomic loops are only expected to be executed once most of the time.

The atomic loops are only expected to be executed once most of the time.

A load compare loop is going to occur more often that just atomic operations though, such as a basic search loop. I was surprised that this didn't come up in the TypePromotion tests, so I have added some.

Maybe we should be checking whether the phi is in a loop or not?

And to clarify, I mean loop header phis.

The atomic loops are only expected to be executed once most of the time.

A load compare loop is going to occur more often that just atomic operations though, such as a basic search loop. I was surprised that this didn't come up in the TypePromotion tests, so I have added some.

OK. Hmm. Those tests don't seem to be effected by this patch. I presume they were meant to be? I've added some other tests that were.

I've been trying to think what to do about it. Best I have so far is to check if there are sinks inside the loops with sources outside. That way we are (potentially) pushing more extends out of the loop, in a way that ISel will do better with.

dmgreen updated this revision to Diff 458873.Sep 8 2022, 2:29 PM
samparker accepted this revision.Sep 12 2022, 1:36 AM

I presume they were meant to be? I've added some other tests that were.

Oh, well... thanks!

Best I have so far is to check if there are sinks inside the loops with sources outside.

Makes sense to me, and looks like it's doing the job.

LGTM.

This revision is now accepted and ready to land.Sep 12 2022, 1:36 AM
This revision was landed with ongoing or failed builds.Sep 13 2022, 12:57 AM
This revision was automatically updated to reflect the committed changes.