[llvm-dev] GEP with a null pointer base

[Chris Lattner via llvm-dev]

Right.  It is turning undefined behavior (load of null) into the canonical pattern that SimplifyCFG picks up.  This is because InstCombine can’t change the CFG.

-Chris

> On Jul 8, 2017, at 7:33 PM, Craig Topper <craig.topper at gmail.com> wrote:
> 
> In this particular case, I believe llvm is really emitting a store of undef to a nullptr. I think this later gets turned into a trap. Here's the relevant code from instcombine.
> 
>   // load(gep null, ...) -> unreachable
>   // load null/undef -> unreachable
>   // TODO: Consider a target hook for valid address spaces for this xforms.
>   if (canSimplifyNullLoadOrGEP(LI, Op)) {
>     // Insert a new store to null instruction before the load to indicate
>     // that this code is not reachable.  We do this instead of inserting
>     // an unreachable instruction directly because we cannot modify the
>     // CFG.
>     new StoreInst(UndefValue::get(LI.getType()),
>                   Constant::getNullValue(Op->getType()), &LI);
>     return replaceInstUsesWith(LI, UndefValue::get(LI.getType()));
>   }
> 
> ~Craig
> 
> On Fri, Jul 7, 2017 at 3:44 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On Jul 7, 2017, at 1:40 PM, Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote:
> > Chris,
> >           The issue the original poster brought up is that instead of a compiler
> > that as you say “makes things work” and “gets the job done” we have a compiler
> > that intentionally deletes “undefined behavior”, on the assumption that since it
> > is the users responsibility to avoid UB this code must be unreachable and
> > is therefore safe to delete.
> >
> > It seems like there are three things the compiler could do with undefined behavior
> > 1)   let the code go through (perhaps with a warning)
> > 2)   replace the code with a trap
> > 3)   optimize the code as unreachable (no warning because we’re assuming this is the users intention)
> 
> Hi Peter,
> 
> I think you have a somewhat fundamental misunderstanding of how UB works (or rather, why it is so crappy and doesn’t really work :-).  The compiler can and does do all three of those, and it doesn’t have to have consistent algorithms for how it picks.  I highly recommend you read some blog posts I wrote about it years ago, starting with:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
> 
> John Regehr also has written a lot on the topic, including the recent post:
> https://blog.regehr.org/archives/1520 <https://blog.regehr.org/archives/1520>
> 
> What you should take from this is that while UB is an inseperable part of C programming, that this is a depressing and faintly terrifying thing.  The tooling built around the C family of languages helps make the situation “less bad”, but it is still pretty bad.  The only solution is to move to new programming languages that don’t inherit the problem of C.  I’m a fan of Swift, but there are others.
> 
> In the case of this particular thread, we aren’t trying to fix UB, we’re trying to switch one very specific syntactic idiom from UB to defined.
> 
> -Chris
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 

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