[llvm-dev] GEP with a null pointer base

[Kaylor, Andrew via llvm-dev]

Hi everyone,

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.

I've discussed this with a few co-workers and we've considered a few possible solutions:

1) Add a new transformation to InstCombine that will replace 'getelementptr i8, i8* null, <ty> %n' with 'inttoptr <ty> %n to i8*' when <ty> has the same size as a pointer for the target architecture.

2) Disable the existing transformation in InstCombine that eliminates the GEP+load.

3) Have the front end recognize this particular idiom and translate it directly as inttoptr.

We like the first solution best.  The second "solution" is basically a punt.  It does away with the immediate problem but leaves the code basically working by chance.  I think the third solution is incomplete, because it relies on the front end being able to detect the use of a null pointer whereas that might not emerge until a few basic optimizations have been performed.

I was hoping to get some more input on this matter before proceeding.

What do you think?

Thanks,
Andy


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