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

[Rafael Espíndola]

lgtm.

On 26 October 2012 11:26, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:
>
> 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)
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>