This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Avoid pointer subtraction of non-integral pointers [WIP]
AbandonedPublic

Authored by reames on Jun 16 2021, 11:00 AM.

Details

Summary

This is a WIP, mostly posted for discussion and performance evaluation.

Over in D104322, and D103660, and a couple other related reviews, there's a desire to avoid pointer math in SCEV. For normal (integral) pointers, we can do this by pushing ptrtoint down expression trees, but we don't have that option for non-integral ones. This patch tries to minimally cripple SCEVs ability to reason about non-integrals, while still allowing forward progress on that idea.

The main impact of this is, from what I can tell, hurting the vectorizers ability to version loops and SCEV-AA. Note that handling ptr - int is important, without that we'd also loose LSR and that's a pretty much fatal flaw.

I'd like to see a performance validation of this patch. @mkazantsev, @skatkov - Can either of you help with that?

Diff Detail

Event Timeline

reames created this revision.Jun 16 2021, 11:00 AM
reames requested review of this revision.Jun 16 2021, 11:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 16 2021, 11:00 AM

This is only going to work if getMinusSCEV() is called directly though.

For normal pointers, I expect that what we want for pointer subtraction (cases where the RHS is a pointer) is to just ptrtoint the operands. It's easy to implement, and the result is intuitive.

Not sure that operation should be part of getMinusSCEV(), or if we should add a separate getPointerDiffSCEV(). Maybe worth separating if getPointerDiffSCEV() is going to be fallible (so getMinusSCEV stays infallible).

If we wanted to optimize getPointerDiffSCEV() for weird pointers, we could try to transform pointer subtraction to integral subtraction if the operands have the same pointer base. Not sure how important this is in practice.

FYI, agree with all the stylistic comments from Eli. Waiting on perf numbers to see if this is worth cleaning up, or if we need a radically different approach.

FYI, I tried to take this patch for performance verification, but it crashed in smoke testing. I haven't yet looked why.

reames abandoned this revision.Jul 8 2021, 4:28 PM