[llvm-dev] GEP with a null pointer base
Kaylor, Andrew via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 11:06:53 PDT 2017
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev