This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Add SCEVCompareExpr node
AbandonedPublic

Authored by reames on Feb 11 2022, 9:54 AM.

Details

Summary

A SCEVCompareExpr node represents the boolean result of performing a comparison as specified by it's predicate and operands. This is essentially an extension of the IR instruction icmp into SCEV.

We've talked about this off and on for a while, but I think it's time to actually do this.

I want to highlight that adding the node does not mean we have to extend IR pattern matching. At the moment, I'm planning on using this to simplify and generalize PredicatedScalarEvolution and the loop versioning checks used by various transforms. The decision as to whether we want these in generic SCEV expressions can (and should be) explicitly deferred here.

Diff Detail

Event Timeline

reames created this revision.Feb 11 2022, 9:54 AM
reames requested review of this revision.Feb 11 2022, 9:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 11 2022, 9:54 AM
reames updated this revision to Diff 407961.Feb 11 2022, 11:06 AM

Fix a bug and add missing piece from expander which showed up when I built on top of this.

I want to highlight that adding the node does not mean we have to extend IR pattern matching. At the moment, I'm planning on using this to simplify and generalize PredicatedScalarEvolution and the loop versioning checks used by various transforms. The decision as to whether we want these in generic SCEV expressions can (and should be) explicitly deferred here.

Could you provide a bit more information on how this is going to be used? It's not completely clear to me whether/why this should be part of the SCEV hierarchy, rather than something that uses SCEV nodes but is not one itself.

Having it as a SCEV makes sense if you want to make it a part of a larger expression, but it's not immediately obvious how that will look in practice (I guess you could use umin/umax as an awkward way to and/or conditions).

I want to highlight that adding the node does not mean we have to extend IR pattern matching. At the moment, I'm planning on using this to simplify and generalize PredicatedScalarEvolution and the loop versioning checks used by various transforms. The decision as to whether we want these in generic SCEV expressions can (and should be) explicitly deferred here.

Could you provide a bit more information on how this is going to be used? It's not completely clear to me whether/why this should be part of the SCEV hierarchy, rather than something that uses SCEV nodes but is not one itself.

So, my current thinking is that SCEVPredicate is just going to end up as a wrapper around a SCEV*. Currently, we have three predicates types - union, compare, and nowrap. My immediate plan is to replace the compare with a wrapped SCEV - I should have a patch shortly. I'd then replace the nowrap variant, and once that's done, do the same for the wrapping union.

I'd originally thought the separate hierarchy make sense as well, but when I started look into it I kept finding myself needing to duplicate logic we already have in SCEV today. (implication, negation, inference, etc..) I really do think it makes sense for predicates to just be SCEV expressions.

Having it as a SCEV makes sense if you want to make it a part of a larger expression, but it's not immediately obvious how that will look in practice (I guess you could use umin/umax as an awkward way to and/or conditions).

We have a way to represent logic or/and in SCEV. Maybe umin/umax is a bit ugly, but we already have precedent for that. Having a single set of simplification and inference rules seems strongly better than having two less well tested implementations which largely duplicate functionality.

mkazantsev added inline comments.Feb 24 2022, 8:59 PM
llvm/lib/Analysis/ScalarEvolution.cpp
4153

I wonder, should we disallow pointer types of LHS and RHS here? I don't see what kind of problems it may bring, just being a bit wary about interpretingo of signed comparisons of pointers.

13232

UDiv -> Cmp

mkazantsev resigned from this revision.Mar 4 2022, 12:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2022, 12:13 AM

ping, any chance I can get an LGTM?

llvm/lib/Analysis/ScalarEvolution.cpp
4153

I actually see one of the advantages of having a scev compare expression as being able to model pointer compares in an analogous way to IR without needing to introduce explicit ptrtoints. Having said that, I'm entirely happy to disable that for now, and discuss that in a separate review. I'd largely forgotten about that aspect, and didn't mean to commingle the discussion.

13232

Agreed, please assume the naming is fixed before landing.

reames abandoned this revision.Oct 24 2022, 9:43 AM

Closing review I'm not currently working on, and am unlikely to get back to in near future. Will reopen if priorities change.