maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/uninit-asm-goto.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

11 lines
209 B
C++
Raw Normal View History

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
// expected-no-diagnostics
int test1(int x) {
int y;
Add 'l' constraint to goto label reference A goto label uses the 'l' constraint, skipping it can cause unexpected warnings.
2020-02-26 03:45:56 +08:00
asm goto("# %0 %1 %l2" : "=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;
}