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

[Kaylor, Andrew via cfe-commits]

The reason I introduced this patch to begin with is that there are circumstances under which the optimizer will eliminate loads from addresses that were generated based on the null pointer arithmetic (because clang previously emitted a null-based GEP and still will in the Firefox case because it's using subtraction).  It would seem that the Firefox case won't ever dereference the pointer it is creating this way, so it should be safe from the optimization I was seeing.

On the other hand, what the warning says is true, right?  I believe clang will produce an inbounds GEP in the Firefox case and the LLVM language reference says, "The only in bounds address for a null pointer in the default address-space is the null pointer itself."  So it's entirely possible that some optimization will interpret the result of the GEP generated to represent '(((char*)0)-1)' as a poison value.

-Andy

-----Original Message-----
From: Sylvestre Ledru via Phabricator [mailto:reviews at reviews.llvm.org] 
Sent: Friday, September 22, 2017 9:02 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>; rjmccall at gmail.com; richard at metafoo.co.uk; efriedma at codeaurora.org
Cc: sylvestre at debian.org; Ivchenko, Alexander <alexander.ivchenko at intel.com>; hfinkel at anl.gov; mcrosier at codeaurora.org; david.majnemer at gmail.com; cfe-commits at lists.llvm.org
Subject: [PATCH] D37042: Teach clang to tolerate the 'p = nullptr + n' idiom used by glibc

sylvestre.ledru added a comment.

For the record, Firefox was using this trick. This patch is breaking a ci build (clang trunk + warning as errors) More information here: https://bugzilla.mozilla.org/show_bug.cgi?id=1402362


Repository:
  rL LLVM

https://reviews.llvm.org/D37042