Improving SCEV's behavior around IR level no-wrap

Hi Sanjoy,

Any update on this?
Are there plans to implement this proposal?

Thanks,
Pankaj

Hi Pankaj,

IIRC there was pushback on this proposal so I did not proceed further.
Are you blocked on this?

[+CC Andy, who I remember had some objections.]

-- Sanjoy

Hi Pankaj,

IIRC there was pushback on this proposal so I did not proceed further.
Are you blocked on this?

[+CC Andy, who I remember had some objections.]

— Sanjoy

Off the top of my head, my concern is that expression comparison is no longer constant time, which I think is fundamental to SCEV.

I may be able to dig through my notes next week, after vacation...

-Andy

I am not blocked by it. I was just wondering whether preserving no-wrap flags in SCEV can help produce better code using SCEVExpander. What I mean is that if I construct SCEV out of incoming optimized IR and then use SCEVExpander to generate code, can I recover the optimized IR back using some combination of peephole optimizations (like instcombine) on the generated code? Or are we going to lose performance due to missing no-wrap flags?

Unfortunately, I do not have a test case to demonstrate that we may lose performance in some cases.

Thanks,
Pankaj

Hi,

I am not blocked by it. I was just wondering whether preserving no-wrap flags in SCEV can help produce better code using SCEVExpander. What I mean is that if I construct SCEV out of incoming optimized IR and then use SCEVExpander to generate code, can I recover the optimized IR back using some combination of peephole optimizations (like instcombine) on the generated code? Or are we going to lose performance due to missing no-wrap flags?

I'm fairly certain that there are cases where round-tripping through
SCEV -> SCEVExpander will lose information for good in clang-generated
IR, since most of the NSW flags in clang-generated IR come language
axioms (signed integer overflow is UB) that can't be re-proved by any
analysis once they've been erased.

-- Sanjoy