[llvm-dev] [EXT] Inline ASM Question

[Krzysztof Parzyszek via llvm-dev]

This is a bug in X86's ISel lowering: it does not take "getBooleanContents" into account when extending the immediate value to 64 bits:

  case 'i': {
    // Literal immediates are always ok.
    if (ConstantSDNode *CST = dyn_cast<ConstantSDNode>(Op)) {
      // Widen to 64 bits here to get it sign extended.
      Result = DAG.getTargetConstant(CST->getSExtValue(), SDLoc(Op), MVT::i64);
      break;
    }

-- 
Krzysztof Parzyszek  mailto:kparzysz at quicinc.com   LLVM compiler development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Bill Wendling via llvm-dev
Sent: Wednesday, April 3, 2019 1:30 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] Inline ASM Question

The code below is triggering some weird behavior that's different from how gcc treats this inline asm. Clang keeps the original type of "loc" as "bool", which generates an "i1 true" after inlining. So far so good. However, during ISEL, the "true" is converted to a signed integer. So when it's evaluated, the result is this:

    .quad	(42+(-1))-.Ltmp0

(notice the "-1"). GCC emits a positive one instead:

    .quad	42 + 1 - .Ltmp0

I'm not sure where the problem lies. Should the inline asm promote the "i1" to "i32" during ISEL? Should it be promoted during inlining? Is there a situation where we require the value to be "i1"?

-bw

typedef _Bool bool;

static inline
__attribute__((__always_inline__))
bool bar(bool loc) {
        asm(".quad 42 + %c0 - .\n\t" : : "i" (loc));
        return 1;
}

int foo(void) {
        return bar(1);
}