[PATCH] D17201: [SCEV] Introduce a guarded backedge taken count and use it in LAA and LV
Sanjoy Das via llvm-commits
llvm-commits at lists.llvm.org
Mon Mar 14 11:21:11 PDT 2016
sanjoy added a subscriber: atrick.
Comment at: include/llvm/Analysis/ScalarEvolution.h:557
@@ -545,1 +556,3 @@
+ /// otherwise it's all CouldNotCompute.
+ SCEVUnionPredicate Pred;
> sanjoy wrote:
> > Now that you're embedding `SCEVUnionPredicate` in every
> > `ExitNotTakenInfo`, I'm somewhat worried about the `SmallVector<const
> > SCEVPredicate *, 16> Preds;` :)
> > Firstly, what is the typical number of predicates we see? 16 seems
> > higher that what I would expect.
> > Secondly, a better (in terms of memory consumption) solution would be
> > to have a `std::unique_ptr<SCEVUnionPredicate>` here, where a null
> > value means "always true" so that in the non-predicated case we only
> > use up one word.
> > The most compact solution (I think we should go with this) is to:
> > - Extract out a `struct ExitNotTakenExtras` that contains a
> > `SmallVector` of `ExitNotTaken` s and a `SCEVUnionPredicate`
> > - Change `PointerIntPair<ExitNotTakenInfo*, 1> NextExit` to
> > `PointerIntPair<ExitNotTakenExtras *, 1> NextExit` where it is
> > usually null, but if it is non-null you either have multiple exits
> > or have some SCEV predicates.
> > Normally I wouldn't worry so much about space, but `ExitNotTakenInfo`
> > has clearly been optimized for space usage, so we should try not to
> > break that.
> Ok, the most common size of the SCEVUnionPredicate there should be 0, so going with your solution makes sense to me.
> On the other hand, it does seem a bit strange to optimize this for memory consumption. I wouldn't expect it to make that much of a difference.
My //guess// is that there are enough `ExitNotTakenInfo` instances floating around in a typical compilation that its size becomes important. But maybe @atrick has a more cogent answer?
More information about the llvm-commits