[PATCH] D102982: [LoopUnroll] Use smallest exact trip count from any exit

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 26 11:35:00 PDT 2021


nikic added a comment.

I just realized what I was confused about in the first place: `getBackedgeTakenCount()` requires that **all** exits have an exact exit count. If you have one unpredicate exit and one exit with an exact exit count, then you'll get back an unpredictable backedge taken count. Only if all exits have an exact exit count will the umin be taken. (This is the `isComplete()` condition in `BackedgeTakenInfo::getExact()`.)

So yes, the exact loop trip count is well-defined for multi-exit loops, but is not available if there is at least one unpredictable exit. However, a loop with one unpredictable exit and one exact exit is exactly the kind of loop I'm interested in here. Loop unrolling occurs against the exact exit, leaving us with TripCount unrolled checks of the unpredictable exit. (This is already supported if the exact trip count is on the latch, while other exits are unpredictable, but not if it's on a non-latch exit.)

In D102982#2782737 <https://reviews.llvm.org/D102982#2782737>, @reames wrote:

> In D102982#2782674 <https://reviews.llvm.org/D102982#2782674>, @nikic wrote:
>
>> @reames Thanks for the patient explanation and me being so dense. No idea what I was thinking here.
>>
>> To loop back around to the unrolling use-case, D103182 <https://reviews.llvm.org/D103182> would now provide us with an exact trip count for the loop. However, I think we still need to use the approach from this patch, or something similar to it, for two reasons:
>>
>> - Without the knowledge //which// exit the trip count is for, we can fold all exits before the TripCount to "not taken", but we don't know which exit is the taken one on the last iteration.
>
> Maybe I'm now being dense, but *why* do we need to know which block was taken?  I'm searching for uses of ExitingBlock in the code, and I can't find it used after the bit of code computing TripCount and TripMultiple.

You're right: If we actually have an exact loop trip count, then we don't. But see my comment above: Here, we actually don't have an exact loop trip count. We have an exact trip count for one exit, while other exits might be unpredictable, and as such cannot be folded at all.

>> - For trip multiples, the "loop trip multiple" would be the minimum of all trip multiples (please correct me if I'm wrong on that!) which I believe is not what is desired for unrolling. If we have one unpredictable exit and one multiple-4 exit, we'd want to unroll against that exit and save use the intermediate branches, but the "loop trip multiple" would be 1 in that case, as we can exit from the loop on every iteration.
>
> So, not minimum of all trip multiples, GCD of the same.  See D103189 <https://reviews.llvm.org/D103189>.
>
> With GCD, I think unrolling gets a huge boost for multiple exit loops.  We can still go further, but we'd need to actual expose multiple multiples to the cost model.  Simply "lying" about the multiple to the costing code seems highly suspect.  (Though, looking at the existing cost modeling code, it looks like it already fudges the multiple.  I have no idea what that code is doing.)
>
> I would request you stage this.  Start with the easy GCD case which is not going to break any assumptions made later in the code (as it is a trip multiple for the loop), then come back to it if you have a motivating example and we can complicate the costing.

I think I'm going to adjust this to not change the trip multiple handling at all in this patch, i.e. only use trip multiple for either a single exit or a latch exit, as before. We can deal with that case separately. I don't think we have good test coverage for this area right now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102982/new/

https://reviews.llvm.org/D102982



More information about the llvm-commits mailing list