r225244 - Sema: analyze I,J,K,M,N,O constraints

[Reid Kleckner]

On Wed, Jan 14, 2015 at 12:47 PM, Joerg Sonnenberger <
joerg at britannica.bec.de> wrote:

> On Sun, Jan 11, 2015 at 02:21:53PM +0100, Joerg Sonnenberger wrote:
> > > 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.
> >
> > Not true, variants like the attached code have been in use for a while.
> > In fact, my clang 3.5.0 build does the correct thing here where ToT now
> > complains.
>
> I am still waiting for an actual test case where ToT or 3.5 didn't
> already bail out. So far this is strictly a regression. Code that
> compiled before failed and as the given example, some code no longer can
> be expressed optimally. It has been discussed on IRC that the x86
> backend is somewhat weak with regards to range checks of immediates, but
> that is a problem with or without inline asm constrraints. In summary:
> I'd like to see this reverted for ToT and 3.6.


I disagree, this is just a new instance of an old problem. See the way we
define this Intel intrinsic:

#define _mm_shuffle_pi16(a, n) __extension__ ({ \
  __m64 __a = (a); \
  (__m64)__builtin_ia32_pshufw((__v4hi)__a, (n)); })

This builtin only works if 'n' is an integer constant. We cannot use an
always_inline wrapper because inlining happens after semantic analysis and
we wish to avoid diagnostics after semantic analysis. There are many
similar intrinsics with this problem, and we always use macros.

This change simply allows us to reject bad code earlier in a more user
friendly way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150114/d770a353/attachment.html>