This attempts to stop the type promotion pass transforming where it is not profitable, by not marking PhiNodes as ToPromote.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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.
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.