Remove trampolines and all of the associated creaky machinery #148
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AlexVlx
requested review from
scchan,
whchung,
bensander,
gstoner,
yxsamliu,
aaronenyeshi and
david-salinas
|
@sameerds FYI. |
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…t-of-thin-air FE generated code use.
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
DenseMap<long, SOMETHING> used LONG_MAX as a tombstone, so it asserts when you try to insert it! rdar://44774672 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343042 91177308-0d34-0410-b5e6-96231b3b80d8
…make ppc64be bots happy. PPC64BE bots use % instead of @ for directives like progbits. Since CFString tests also check asm output, they fail on the following: cfstring3.c:44:19: error: CHECK-ASM-ELF: expected string not found in input // CHECK-ASM-ELF: .section cfstring,"aw",@progbits <stdin>:30:2: note: possible intended match here .section cfstring,"aw",%progbits Updating that check with a {{[@%]}}progbits regex to make those bots happy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343044 91177308-0d34-0410-b5e6-96231b3b80d8
…ymbols. Tests introduced in r329780 was disabled in r342317 because these tests were accidentally testing dump infrastructure, when all they cared about was how symbols relate to each other. So when dump infrastructure changed, tests became annoying to maintain. Add a new feature to ExprInspection: clang_analyzer_denote() and clang_analyzer_explain(). The former adds a notation to a symbol, the latter expresses another symbol in terms of previously denoted symbols. It's currently a bit wonky - doesn't print parentheses and only supports denoting atomic symbols. But it's even more readable that way. Differential Revision: https://reviews.llvm.org/D52133 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343048 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343050 91177308-0d34-0410-b5e6-96231b3b80d8
Commit r340984 causes a crash when a pointer to a completely unrelated type
UnrelatedT (eg., opaque struct pattern) is being casted from base class BaseT to
derived class DerivedT, which results in an ill-formed region
Derived{SymRegion{$<UnrelatedT x>}, DerivedT}.
Differential Revision: https://reviews.llvm.org/D52189
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343051 91177308-0d34-0410-b5e6-96231b3b80d8
…ause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343063 91177308-0d34-0410-b5e6-96231b3b80d8
triggers instantiation of constexpr functions. We mostly implemented this since Clang 6, but missed the template instantiation case. We do not implement the '&cast-expression' special case. It appears to be a mistake / oversight. I've mailed CWG to see if we can remove it. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343064 91177308-0d34-0410-b5e6-96231b3b80d8
Not every FunctionDecl is an identifier. Calling getName() from FunctionDecl without isIdentifier() check leads to an assert in NamedDecl::getName() and as a result to failures in more than 2/3 of HCC unit tests.
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…kernarg on host side.
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ill be usable for host.
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…om/RadeonOpenCompute/hcc-clang-upgrade into feature_trampolines_are_for_babies
…ute/hcc-clang-upgrade into feature_trampolines_are_for_babies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This starts the long road to cleaning up the FE, removing the rather ghastly legacy of the initial MCW implementation of C++AMP. The trampoline / serialisation based mechanism was never truly trustworthy, and it is broken in many subtle ways. This is WiP, but I deemed it useful to have perspective on the scope of the work, as well as have early insight and observe any additional changes as they come along. This also removes things like CPU mode or restrict(auto), neither of which are anything but weird stubs.