[cfe-commits] [PATCH] Handle '*' and '#' asm constraint modifiers

[Ulrich Weigand]

Hello,

system header files on PowerPC Linux contain the following macro:

/* The weird 'i#*X' constraints on the following suppress a gcc
   warning when __excepts is not a constant.  Otherwise, they mean the
   same as just plain 'i'.  */

/* Inline definition for feraiseexcept.  */
# define feraiseexcept(__excepts) \
  ((__builtin_constant_p (__excepts)
\
    && ((__excepts) & ((__excepts)-1)) == 0
\
    && (__excepts) != FE_INVALID)
\
   ? ((__excepts) != 0
\
      ? (__extension__ ({ __asm__ __volatile__
\
                          ("mtfsb1 %s0"
\
                           : : "i#*X"(__builtin_ffs (__excepts)));
\
                          0; }))
\
      : 0)
\
   : (feraiseexcept) (__excepts))

[ The GCC warning refers to a problem in certain older GCC version, where
you'd get a warning when using an "i" inline assembler constraint with a
non-constant operand -- even if the code could never be executed because it
was guarded by a __builtin_constant_p check. ]

This code fails to compile with clang, since it doesn't understand the '*'
and '#' constraint modifiers.  '*' means to ignore the rest of the
constraint alternative for purposes of computing register preferences, and
'#' means to ignore the rest of the constraint alternative as actual
constraint, and *only* consider it for computing register preferences.   A
combination of both thus means ignoring the rest of the constraint
alternative completely for code generation (but apparently not necessarily
for purposes of semantical checks in the front end).

The attached patch makes this code compile by just skipping '*' and '#'
when checking constraint validity in TargetInfo::validateInputConstraint
and TargetInfo::validateOutputConstraint, and ignoring the rest of the
alternative after '#' in SimplifyConstraint for code generation -- since
LLVM doesn't seem to use constraints for "register preferences" like GCC
does.  (The latter routine already ignores '*' but keeps using the rest of
the alternative; this seems correct since those are still valid as
constraints.)

Is this OK to commit?

Thanks,
Ulrich

(See attached file: diff-clang-asmconstraint)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-clang-asmconstraint
Type: application/octet-stream
Size: 1688 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121026/fed5cd62/attachment.obj>