[llvm-dev] GEP with a null pointer base

[Kaylor, Andrew via llvm-dev]

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else?

I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom.

The most recent glibc code is a bit more complicated than I represented below.  If you look up obstack.h you can see what’s there now.  Basically, they’re computing a pointer alignment that may be based on some non-null base pointer or may be based on null, depending on the target architecture.  I’m sure it’s possible to make it more sensible, but I’ve never interacted with the glibc community so I’m not sure how open they would be to changing this.  I suspect I’d need a more compelling argument than clang-compatibility (or maybe even standards compatibility).

From: James Y Knight [mailto:jyknight at google.com]
Sent: Thursday, July 06, 2017 12:06 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] GEP with a null pointer base



On Thu, Jul 6, 2017 at 2:06 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
I've got a problem that I would like some input on.  The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this:

  p = (char*)0 + n

where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer.

clang translates this as

  %p = getelementptr inbounds i8, i8* null, i64 %n

So far, so good.  The problem is that while LLVM seems to consider the above IR to be valid, we officially do not allow dereferencing a pointer constructed in this way (if I’m reading the rules correctly).  Consequently, if this GEP ever gets close enough to a load using the pointer, InstCombine will eliminate the GEP and the load.

I've been told that the '(char*)0 + n' construct is invalid according to the C standard.  However, this pattern appears in the glibc malloc implementation, so I'd like to be able to handle it anyway.

glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else?


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