Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
// RUN: %clang_cc1 -std=c++11 -Wuninitialized -verify %s
|
|
|
|
|
2020-03-11 04:47:30 +08:00
|
|
|
// test1: Expect no diagnostics
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
int test1(int x) {
|
|
|
|
int y;
|
2020-02-26 04:31:20 +08:00
|
|
|
asm goto("nop" : "=r"(y) : "r"(x) : : err);
|
Support output constraints on "asm goto"
Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.
Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.
In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.
Reviewers: jyknight, nickdesaulniers, hfinkel
Reviewed By: jyknight, nickdesaulniers
Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69876
2020-02-25 10:32:50 +08:00
|
|
|
return y;
|
|
|
|
err:
|
|
|
|
return -1;
|
|
|
|
}
|
2020-03-11 04:47:30 +08:00
|
|
|
|
|
|
|
int test2(int x) {
|
|
|
|
int y; // expected-warning {{variable 'y' is used uninitialized whenever its declaration is reached}} \
|
|
|
|
// expected-note {{initialize the variable}}
|
|
|
|
if (x < 42)
|
|
|
|
asm volatile goto("testl %0, %0; testl %1, %2; jne %l3" : "+S"(x), "+D"(y) : "r"(x) :: indirect_1, indirect_2);
|
|
|
|
else
|
|
|
|
asm volatile goto("testl %0, %1; testl %2, %3; jne %l5" : "+S"(x), "+D"(y) : "r"(x), "r"(y) :: indirect_1, indirect_2);
|
|
|
|
return x + y;
|
|
|
|
indirect_1:
|
|
|
|
return -42;
|
|
|
|
indirect_2:
|
|
|
|
return y; // expected-note {{uninitialized use occurs here}}
|
|
|
|
}
|
|
|
|
|
|
|
|
int test3(int x) {
|
|
|
|
int y; // expected-warning {{variable 'y' is used uninitialized whenever its declaration is reached}} \
|
|
|
|
// expected-note {{initialize the variable}}
|
|
|
|
asm goto("xorl %1, %0; jmp %l2" : "=&r"(y) : "r"(x) : : fail);
|
|
|
|
normal:
|
|
|
|
y += x;
|
|
|
|
return y;
|
|
|
|
if (x) {
|
|
|
|
fail:
|
|
|
|
return y; // expected-note {{uninitialized use occurs here}}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int test4(int x) {
|
|
|
|
int y; // expected-warning {{variable 'y' is used uninitialized whenever its declaration is reached}} \
|
|
|
|
// expected-note {{initialize the variable}}
|
|
|
|
goto forward;
|
|
|
|
backward:
|
|
|
|
return y; // expected-note {{uninitialized use occurs here}}
|
|
|
|
forward:
|
|
|
|
asm goto("# %0 %1 %2" : "=r"(y) : "r"(x) : : backward);
|
|
|
|
return y;
|
|
|
|
}
|
|
|
|
|
|
|
|
// test5: Expect no diagnostics
|
|
|
|
int test5(int x) {
|
|
|
|
int y;
|
|
|
|
asm volatile goto("testl %0, %0; testl %1, %2; jne %l3" : "+S"(x), "+D"(y) : "r"(x) :: indirect, fallthrough);
|
|
|
|
fallthrough:
|
|
|
|
return y;
|
|
|
|
indirect:
|
|
|
|
return -2;
|
|
|
|
}
|