[llvm-dev] GEP with a null pointer base

[Chris Lattner via llvm-dev]

> On Jul 6, 2017, at 12:28 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> 
> I’m not entirely opposed to solution #3.  As I said, my concern is that there are cases it would miss.
>  
> For instance, if I had some code like this:
>  
> char *get_ptr(char *base, intptr_t offset) {
>   return base + offset;
> }
>  
> char *convert_to_ptr(intptr_t ptr_val) {
>   return get_ptr((char*)0, ptr_val);
> }
>  
> There the idiom would only appear after inlining, so the front end couldn’t handle it. 

Agreed, but that is a good thing, not a bad thing.  The whole point here is that we want to limit the impact to only occur for the cases that matter.  This would be a source compatibility hack, not a general extension to the IR.

> The current glibc code is implemented with a couple of layers of macros that have a logical branch that could theoretically result in the null coming in via a PHI, but some early investigation makes it look like the choice between null and something else is actually resolved in the front end in some way.  If that holds up and it turns out that I don’t have any actual programs where the front end can’t spot this idiom (and I agree it’s horrible) maybe it would be acceptable to not handle the theoretical cases.

Macros shouldn’t pose a problem.  Clang has several recursive AST walkers that could help you.  For example, it has a “is a null pointer expression” predicate, which will walk through casts and other nonsense that may be in the way of detecting the zero.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/29422ac0/attachment.html>