<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 10, 2015 at 6:25 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 06, 2015 at 04:26:34AM -0000, Saleem Abdulrasool wrote:<br>
> Author: compnerd<br>
> Date: Mon Jan  5 22:26:34 2015<br>
> New Revision: 225244<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=225244&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=225244&view=rev</a><br>
> Log:<br>
> Sema: analyze I,J,K,M,N,O constraints<br>
><br>
> Add additional constraint checking for target specific behaviour for inline<br>
> assembly constraints.  We would previously silently let all arguments through<br>
> for these constraints.  In cases where the constraints were violated, we could<br>
> end up failing to select instructions and triggering assertions or worse,<br>
> silently ignoring instructions.<br>
<br>
</span>As discussion on IRC, I think the change is incorrect at least for 'K'.<br>
It makes it impossible to encapsulate the equivalent to certain MMX/SSE<br>
intrinsincs with always_inline functions, creating a regression for<br>
pixman for example. We already have logic in the backend to ensure that<br>
doesn't happen. In short: it is fine to verify that the constraint *can<br>
be* be fulfilled, but it is not acceptable to require immediates in<br>
cases where the inliner or GVN would be able to compute constant<br>
arguments later.</blockquote></div><br>FWIW, I disagree.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Accepting or rejecting code should be stable across optimizations. If Clang can't reliably fold the argument to a constant, I think it is important to reject it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is not the first time that Clang has disagreed with GCC on this specific front -- we also refuse to use the optimizer to implement __builtin_constant_p because it would produce unpredictable results and violates fundamental layering design decisions in LLVM and Clang.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fortunately, pixman is the only example of code I have seen that was regressed by this, and the code in pixman I think can even fail with GCC under the right circumstances, so I don't see this as a problem.</div></div>