Skip to content

Conversation

@fhahn
Copy link
Contributor

@fhahn fhahn commented Sep 2, 2025

Update evaluatePtrAddrecAtMaxBTCWillNotWrap to support non-constant sizes in dereferenceable assumptions.

Note that with that we will need to add a constant to a backedge-taken-count, so expressions like (-1 + %n) + 1. While adding something to -1 technically wraps in the unsigned sense, in practice the result should not consider overflowing in addSCEVNoOverflow. I am not sure if there's a more general place for this kind of reasoning?

Update evaluatePtrAddrecAtMaxBTCWillNotWrap to support non-constant
sizes in dereferenceable assumptions.

Note that with that we will need to add a constant to a backedge-taken-count, so
expressions like (-1 + %n) + 1. While adding something to -1 technically
wraps in the unsigned sense, in practice the result should not consider
overflowing in addSCEVNoOverflow. I am not sure if there's a more
general place for this kind of reasoning?
@efriedma-quic
Copy link
Collaborator

efriedma-quic commented Sep 2, 2025

technically wraps in the unsigned sense, in practice the result should not consider overflowing in addSCEVNoOverflow

I don't see any obvious reason it's safe to conclude the computation can't overflow. Loops with BTC of "n-1" usually have a trip count of "n", but you can easily write code to violate that, like void f(unsigned n, void g(void)) { unsigned i = 0; do { g(); i++; } while (i != n); }.

@fhahn
Copy link
Contributor Author

fhahn commented Sep 3, 2025

Argh yes, this was a stale change and should be taken care with info from loop guards.

@fhahn fhahn closed this Sep 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants