<div dir="ltr">On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>So IIUC basically the *only* reason for this IR change is that we don’t want to pattern match in debug build?</div><div>I don't understand right now why we wouldn’t want to do this?</div></div></blockquote><div><br></div><div>If we need to pattern match such a basic construct, it suggests to me that we have the wrong representation, and we should instead make our representation more accurately model reality. To me, it feels like this representation allows several good things to just "fall out" without any additional work, and that suggests it's a good representation.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 5:47 PM, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One other questionable side benefit of doing this is that it would make it possible to implement va_start by taking the address of a parameter and doing pointer arithmetic. While that code is fairly invalid, it’s exactly what the MSVC STL headers do for 32-bit x86. If we make this work in Clang, we can remove our stdarg.h and vadefs.h wrapper headers. Users often pass flags that cause clang to skip these wrapper headers, and then they file bugs complaining that va lists don't work.<br>
</blockquote>
<br></span>
This ignores the other reason why this doesn't work at the moment: reading off the end of an alloca returns undef, whether or not the actual pointer value points at the data you want.  I mean, it's not impossible to make it work, but it involves a bunch of unrelated changes which I don't think we want to pursue.</blockquote><div><br></div><div>I guess I'm more willing to pursue those changes at some vague unspecified point in the future. It doesn't seem that crazy to add a special case to allow OOB GEPs of off the last argument alloca of a variadic function. Other OOB GEPs can continue to be UB as they are today. We have other loopholes for these kinds of OOB GEP optimizations around zero-sized globals so that people can use __start_section/__stop_section symbols to implement .init_array style registration systems. This doesn't seem that different.</div></div></div></div>