[PATCH] D37042: Teach clang to tolerate the 'p = nullptr + n' idiom used by glibc

[Andy Kaylor via Phabricator via cfe-commits]

andrew.w.kaylor added a comment.

My intention here was to make this as strict/limited as possible while still handling the cases of interest.  There are two different implementations I want to handle.  You can see the first variation in the __BPTR_ALIGN definition being added here:

https://github.com/lattera/glibc/commit/2fd4de4b15a66f821057af90714145d2c034a609#diff-cd0c2b2693d632ad8843ae58a6ea7ffaR125

You can see the other in the __INT_TO_PTR definition that was being deleted in the same change set here:

https://github.com/lattera/glibc/commit/2fd4de4b15a66f821057af90714145d2c034a609#diff-cd0c2b2693d632ad8843ae58a6ea7ffaL122

This second case shows up in some benchmark code, so it's important even though glibc phased it out.

I'm really not sure what this looks like in the front end, but it seems like it could be relatively open-ended as to where the value came from.

Basically, my intention is to eliminate anything I know isn't what I'm looking for and then handle whatever remains being added to a null pointer.  Given that adding to a null pointer is undefined behavior, whatever we do should be acceptable in all cases.  What I found in practice was that even with the existing handling of this it took an awful lot of optimizations before the null-based GEP and the load associated with it got close enough together for us to recognize that we could optimize it away, so I don't think we'd be losing much by tolerating additional cases in the way this patch proposes.


https://reviews.llvm.org/D37042