<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 9, 2017 at 1:10 PM, Marcin Słowik via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can we go back a little?<div class="gmail_extra"><br><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div></span><div>What's the actual problem with this approach? I personally find it the most compelling - it is well-defined (well, somewhat), front-end agnostic (and assume some front ends may find this kind of pointer arithmetic to be well-defined) and predictable. </div><div>I would even extend it to allow offsets of different types to be used, with additional zero-extension when applicable.</div></div></div></div></blockquote><div><br></div><div>This would make correctness of a program dependent on running a particular optimization pass, something which is not sound from a semantics point of view (what if another pass sees the gep of null before InstCombine does, etc.).</div><div><br></div><div>LLVM IR has semantics, properties which we are supposed to use to reason about what a particular piece of IR does. This proposed transformation, while legal, is not mandatory. Making it mandatory means more than adding one particular change to InstCombine: it means a change to the semantics of LLVM IR. This way we require that all passes, analysis, etc. treat gep null in an appropriate way.</div><div><br></div><div>There are many reasons why such a semantic shift would be undesirable:</div><div>- It opens up a pandora's box with regard to the semantics of transformations on GEPs when commuted and combined with other GEPs</div><div>- It results in less expresivity: frontends should emit the IR that match the semantics of their source language. Constraining GEP semantics would constrain it for frontends which do not want or need this semantic shift.</div><div><br></div><div>If the goal is to make (char*)0 + n work in clang, clang should be the bearer of that burden. It is not difficult to implement this in AST->IR lowering and has several benefits:</div><div>- No change to GEP semantics which means that existing optimizations are sound.</div><div>- Easy to explain why, when and how clang's behavior shifts with regards to particular source expressions and their lowering.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Cheers,</div><div>Marcin</div></div>
</div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>