<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2017, at 1:00 PM, via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""> So far, so good. The problem is that while LLVM seems to consider<br class=""> the above IR to be valid, we officially do not allow dereferencing<br class=""> a pointer constructed in this way (if I’m reading the rules<br class=""> correctly). Consequently, if this GEP ever gets close enough to a<br class=""> load using the pointer, InstCombine will eliminate the GEP and the<br class=""> load.</blockquote></div></blockquote></div><br class=""><div class="">This is the part that confuses me, why would such code be eliminated.</div><div class="">If it is illegal then this should be a compilation failure,</div><div class="">If it is legal then either you prefer to let it compile as is,</div><div class="">or you prefer to allow “undefined behavior optimization” to take effect,</div><div class="">In which case it is not the load instruction that should be deleted but</div><div class="">rather then entire block containing the load (under the assumption</div><div class="">that “undefined behavior” is unreachable) and InstCombine isn’t the</div><div class="">place to do that.</div><div class=""><br class=""></div><div class="">Confused,</div><div class="">Peter Lawrence.</div></body></html>