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

[Saleem Abdulrasool]

On Sat, Jan 10, 2015 at 6:25 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Tue, Jan 06, 2015 at 04:26:34AM -0000, Saleem Abdulrasool wrote:
> > Author: compnerd
> > Date: Mon Jan  5 22:26:34 2015
> > New Revision: 225244
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=225244&view=rev
> > Log:
> > Sema: analyze I,J,K,M,N,O constraints
> >
> > Add additional constraint checking for target specific behaviour for
> inline
> > assembly constraints.  We would previously silently let all arguments
> through
> > for these constraints.  In cases where the constraints were violated, we
> could
> > end up failing to select instructions and triggering assertions or worse,
> > silently ignoring instructions.
>
> As discussion on IRC, I think the change is incorrect at least for 'K'.
> It makes it impossible to encapsulate the equivalent to certain MMX/SSE
> intrinsincs with always_inline functions, creating a regression for
> pixman for example. We already have logic in the backend to ensure that
> doesn't happen. In short: it is fine to verify that the constraint *can
> be* be fulfilled, but it is not acceptable to require immediates in
> cases where the inliner or GVN would be able to compute constant
> arguments later.


I disagree with this.  Without optimizations, always_inline can still be
insufficient to cause the folding that you want:

static inline unsigned int __attribute__((__always_inline__))
RORc(unsigned int word, const int i) {
  asm("rorl %2,%0" : "=r"(word) : "0"(word), "K"(i));
  return word;
}
int test(void) {
  return RORc(32, 4);
}

Without optimizations, this will fail in the backend.

Inline assembly is inherently fragile.  If we really can't guarantee it,
then we should catch this upfront, where we can provide better
diagnostics.  This also enables us to be more consistent in what code we
accept (e.g. the trick that pixmap uses to switch between a macro and a
function no longer applies).


> Joerg
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150110/21351f1d/attachment.html>