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);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190402/4fd82f5f/attachment.html>
Krzysztof Parzyszek via llvm-dev
2019-Apr-03 15:13 UTC
[llvm-dev] [EXT] Inline ASM Question
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);
}
Krzysztof Parzyszek via llvm-dev
2019-Apr-03 16:10 UTC
[llvm-dev] [EXT] Inline ASM Question
https://reviews.llvm.org/D60208
--
Krzysztof Parzyszek kparzysz at quicinc.com LLVM compiler development
-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof
Parzyszek via llvm-dev
Sent: Wednesday, April 3, 2019 10:13 AM
To: Bill Wendling <isanbard at gmail.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [EXT] Inline ASM Question
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);
}
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev