|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
2e603c67 |
| 11-Jun-2022 |
Kazu Hirata <[email protected]> |
[clang] Construct SmallVector with iterator ranges (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
a1dcfb75 |
| 22-Mar-2022 |
Nathan Sidwell <[email protected]> |
[clang] Module global init mangling
C++20 modules require emission of an initializer function, which is called by importers of the module. This implements the mangling for that function. It is the
[clang] Module global init mangling
C++20 modules require emission of an initializer function, which is called by importers of the module. This implements the mangling for that function. It is the one place the ABI exposes partition names in symbols -- but fortunately only needed by other TUs of that same module.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D122741
show more ...
|
| #
83c431fb |
| 20-May-2022 |
Jon Chesterfield <[email protected]> |
[amdgpu] Add amdgpu_kernel calling conv attribute to clang
Allows emitting define amdgpu_kernel void @func() IR from C or C++.
This replaces the current workflow which is to write a stub in opencl
[amdgpu] Add amdgpu_kernel calling conv attribute to clang
Allows emitting define amdgpu_kernel void @func() IR from C or C++.
This replaces the current workflow which is to write a stub in opencl that calls an external C function implemented in C++ combined through llvm-link.
Calling the resulting function still requires a manual implementation of the ABI from the host side. The primary application is for more rapid debugging of the amdgpu backend by permuting a C or C++ test file instead of manually updating an IR file.
Implementation closely follows D54425. Non-amd reviewers from there.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D125970
show more ...
|
| #
75bb8152 |
| 29-Mar-2022 |
Matt Devereau <[email protected]> |
[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang
Enable function attribute aarch64_sve_pcs at the C level, which correspondes to aarch64_sve_vector_pcs at the LLVM IR level.
This requirement w
[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang
Enable function attribute aarch64_sve_pcs at the C level, which correspondes to aarch64_sve_vector_pcs at the LLVM IR level.
This requirement was created by this addition to the ARM C Language Extension: https://github.com/ARM-software/acle/pull/194
Differential Revision: https://reviews.llvm.org/D124998
show more ...
|
| #
62501bc4 |
| 03-May-2022 |
Yaxun (Sam) Liu <[email protected]> |
[NFC][CUDA][HIP] rework mangling number for aux target
CUDA/HIP needs to mangle for aux target. When mangling for aux target, the mangler should use mangling number for aux target. Previously in htt
[NFC][CUDA][HIP] rework mangling number for aux target
CUDA/HIP needs to mangle for aux target. When mangling for aux target, the mangler should use mangling number for aux target. Previously in https://reviews.llvm.org/D122734 a state was introduced in ASTContext to let the mangler get mangling number for aux target from ASTContext. This patch removes that state from ASTConext and add an IsAux member to MangleContext to indicate that the mangle context is for aux target. This reflects the reality that the mangle context is created for mangling aux target and makes ASTContext cleaner.
Reviewed by: Artem Belevich, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D124842
show more ...
|
| #
fed7be09 |
| 02-May-2022 |
Harald van Dijk <[email protected]> |
Mark identifier prefixes as substitutable
The Itanium C++ ABI says prefixes are substitutable. For most prefixes we already handle this: the manglePrefix(const DeclContext *, bool) and manglePrefix(
Mark identifier prefixes as substitutable
The Itanium C++ ABI says prefixes are substitutable. For most prefixes we already handle this: the manglePrefix(const DeclContext *, bool) and manglePrefix(QualType) overloads explicitly handles substitutions or defer to functions that handle substitutions on their behalf. The manglePrefix(NestedNameSpecifier *) overload, however, is different and handles some cases implicitly, but not all. The Identifier case was not handled; this change adds handling for it, as well as a test case.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122663
show more ...
|
| #
864752cf |
| 21-Apr-2022 |
Haojian Wu <[email protected]> |
[AST] QualifiedTemplateName::getTemplateDecl cleanup.
This is a followup cleanup of 1234b1c6d8113d50beef5801be607ad1d502b2f7
Differential Revision: https://reviews.llvm.org/D124238
|
| #
6ba1b907 |
| 12-Apr-2022 |
Haojian Wu <[email protected]> |
Reland "[AST] Add a new TemplateKind for template decls found via a using decl.""
This is the template version of https://reviews.llvm.org/D114251.
This patch introduces a new template name kind (U
Reland "[AST] Add a new TemplateKind for template decls found via a using decl.""
This is the template version of https://reviews.llvm.org/D114251.
This patch introduces a new template name kind (UsingTemplateName). The UsingTemplateName stores the found using-shadow decl (and underlying template can be retrieved from the using-shadow decl). With the new template name, we can be able to find the using decl that a template typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template, which is useful for tooling use cases (include cleaner etc).
This patch merely focuses on adding the node to the AST.
Next steps: - support using-decl in qualified template name; - update the clangd and other tools to use this new node; - add ast matchers for matching different kinds of template names;
Differential Revision: https://reviews.llvm.org/D123127
show more ...
|
| #
95f0f69f |
| 12-Apr-2022 |
Haojian Wu <[email protected]> |
Revert "[AST] Add a new TemplateKind for template decls found via a using decl."
It breaks arm build, there is no free bit for the extra UsingShadowDecl in TemplateName::StorageType.
Reverting it t
Revert "[AST] Add a new TemplateKind for template decls found via a using decl."
It breaks arm build, there is no free bit for the extra UsingShadowDecl in TemplateName::StorageType.
Reverting it to build the buildbot back until we comeup with a fix.
This reverts commit 5a5be4044f0bceb71bb6a81f6955704691b389ed.
show more ...
|
| #
5a5be404 |
| 11-Apr-2022 |
Haojian Wu <[email protected]> |
[AST] Add a new TemplateKind for template decls found via a using decl.
This is the template version of https://reviews.llvm.org/D114251.
This patch introduces a new template name kind (UsingTempla
[AST] Add a new TemplateKind for template decls found via a using decl.
This is the template version of https://reviews.llvm.org/D114251.
This patch introduces a new template name kind (UsingTemplateName). The UsingTemplateName stores the found using-shadow decl (and underlying template can be retrieved from the using-shadow decl). With the new template name, we can be able to find the using decl that a template typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template, which is useful for tooling use cases (include cleaner etc).
This patch merely focuses on adding the node to the AST.
Next steps: - support using-decl in qualified template name; - update the clangd and other tools to use this new node; - add ast matchers for matching different kinds of template names;
Differential Revision: https://reviews.llvm.org/D123127
show more ...
|
| #
d1205bb3 |
| 04-Apr-2022 |
Erich Keane <[email protected]> |
Reapply"[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"
AND the followups that fixed builds.
I attempted to get 'cute' and use llvm-cxxfilt to make the test look nicer, but
Reapply"[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"
AND the followups that fixed builds.
I attempted to get 'cute' and use llvm-cxxfilt to make the test look nicer, but apparently some of the bots have a version of llvm-cxxfilt that is not the in-tree one, so it fails to properly demangle the stuff. I've disabled this "RUN" line.
This reverts commit 50186b63d1807d389f31c515377d94185795ab44.
show more ...
|
| #
50186b63 |
| 03-Apr-2022 |
Nico Weber <[email protected]> |
Revert "[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"
This reverts commit 4cf98f973a13c5049322abff43f0dff3c214311b. The test fails on mac bots, see comments on https://revi
Revert "[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"
This reverts commit 4cf98f973a13c5049322abff43f0dff3c214311b. The test fails on mac bots, see comments on https://reviews.llvm.org/D122820
Also reverts follow-ups eb920989865d992093993143ba3c6e71126cbb89 and 861c189d2a5203ba8c8e983e8d2e109c0de153a5.
show more ...
|
| #
4cf98f97 |
| 31-Mar-2022 |
Erich Keane <[email protected]> |
[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs
As reported in https://github.com/llvm/llvm-project/issues/54588 and discussed in https://github.com/itanium-cxx-abi/cxx-abi/is
[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs
As reported in https://github.com/llvm/llvm-project/issues/54588 and discussed in https://github.com/itanium-cxx-abi/cxx-abi/issues/139
We are supposed to do a DFS, pre-order, decl-order search for a name for the union in this case. Prevoiusly we crashed because the IdentiferInfo pointer was nullptr, so this makes sure we have a name in the cases described by the ABI.
I added an llvm-unreachable to cover an unexpected case at the end of the new function with information/reference to the ABI in case we come up with some way to get back to here.
Differential Revision: https://reviews.llvm.org/D122820
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
ae4dce86 |
| 18-Jan-2022 |
Nathan Sidwell <[email protected]> |
[clang][ABI] New C++20 module mangling scheme
Implement a demangleable strong ownership symbol mangling.
* The original module symbol mangling scheme turned out to be undemangleable.
* The hoped
[clang][ABI] New C++20 module mangling scheme
Implement a demangleable strong ownership symbol mangling.
* The original module symbol mangling scheme turned out to be undemangleable.
* The hoped-for C++17 compatibility of weak ownership turns out to be fragile
* C++20 now has better ways of controlling C++17 compatibility
The issue is captured on the ABI list at: https://github.com/itanium-cxx-abi/cxx-abi/issues/134
GCC implements this new mangling.
The old mangling is unceremoniously dropped. No backwards compatibility, no deprectated old-mangling flag. It was always labelled experimental. (Old and new manglings cannot be confused.)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122256
show more ...
|
| #
3251ba2d |
| 04-Mar-2022 |
Yonghong Song <[email protected]> |
[Attr] Fix a btf_type_tag AST generation
Current ASTContext.getAttributedType() takes attribute kind, ModifiedType and EquivType as the hash to decide whether an AST node has been generated or note.
[Attr] Fix a btf_type_tag AST generation
Current ASTContext.getAttributedType() takes attribute kind, ModifiedType and EquivType as the hash to decide whether an AST node has been generated or note. But this is not enough for btf_type_tag as the attribute might have the same ModifiedType and EquivType, but still have different string associated with attribute.
For example, for a data structure like below, struct map_value { int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a; int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b; }; The current ASTContext.getAttributedType() will produce an AST similar to below: struct map_value { int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a; int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b; }; and this is incorrect.
It is very difficult to use the current AttributedType as it is hard to get the tag information. To fix the problem, this patch introduced BTFTagAttributedType which is similar to AttributedType in many ways but with an additional BTFTypeTagAttr. The tag itself can be retrieved with BTFTypeTagAttr. With the new BTFTagAttributed type, the debuginfo code can be greatly simplified compared to previous TypeLoc based approach.
Differential Revision: https://reviews.llvm.org/D120296
show more ...
|
| #
845f0bb5 |
| 09-Mar-2022 |
Chuanqi Xu <[email protected]> |
Revert "[clang][ABI] New C++20 module mangling scheme"
This reverts commit 21e16ab6b8ddaccb70d2344bb35419e214a32ec9.
It looks like it would break builds in mac. See https://reviews.llvm.org/D118352.
|
| #
21e16ab6 |
| 18-Jan-2022 |
Nathan Sidwell <[email protected]> |
[clang][ABI] New C++20 module mangling scheme
The existing module symbol mangling scheme turns out to be undemangleable. It is also desirable to switch to the strong-ownership model as the hoped-fo
[clang][ABI] New C++20 module mangling scheme
The existing module symbol mangling scheme turns out to be undemangleable. It is also desirable to switch to the strong-ownership model as the hoped-for C++17 compatibility turns out to be fragile, and we also now have a better way of controlling that.
The issue is captured on the ABI list at: https://github.com/itanium-cxx-abi/cxx-abi/issues/134
A document describing the issues and new mangling is at: https://drive.google.com/file/d/1qQjqptzOFT_lfXH8L6-iD9nCRi34wjft/view
This patch is the code-generation part. I have a demangler too, but that patch is based on some to-be-landed refactoring of the demangler.
The old mangling is unceremoniously dropped. No backwards compatibility, no deprectated old-mangling flag. It was always labelled experimental. (Old and new manglings cannot be confused.)
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118352
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
82e5f951 |
| 06-Jan-2022 |
Peter Collingbourne <[email protected]> |
AST: Move __va_list tag back to std conditionally on AArch64.
In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespac
AST: Move __va_list tag back to std conditionally on AArch64.
In post-commit feedback on D104830 Jessica Clarke pointed out that unconditionally adding __va_list to the std namespace caused namespace debug info to be emitted in C, which is not only inappropriate but turned out to confuse the dtrace tool. Therefore, move __va_list back to std only in C++ so that the correct debug info is generated. We also considered moving __va_list to the top level unconditionally but this would contradict the specification and be visible to AST matchers and such, so make it conditional on the language mode.
To avoid breaking name mangling for __va_list, teach the Itanium name mangler to always mangle it as if it were in the std namespace when targeting ARM architectures. This logic is not needed for the Microsoft name mangler because Microsoft platforms define va_list as a typedef of char *.
Depends on D116773
Differential Revision: https://reviews.llvm.org/D116774
show more ...
|
| #
18ead233 |
| 17-Feb-2022 |
Peter Collingbourne <[email protected]> |
AST: Make getEffectiveDeclContext() a member function of ItaniumMangleContextImpl. NFCI.
In an upcoming change we are going to need to access mangler state from the getEffectiveDeclContext() functio
AST: Make getEffectiveDeclContext() a member function of ItaniumMangleContextImpl. NFCI.
In an upcoming change we are going to need to access mangler state from the getEffectiveDeclContext() function. Therefore, make it a member function of ItaniumMangleContextImpl. Any callers that are not currently members of ItaniumMangleContextImpl or CXXNameMangler are made members of one or the other depending on where they are called from.
Differential Revision: https://reviews.llvm.org/D116773
show more ...
|
| #
082f3288 |
| 11-Feb-2022 |
Nathan Sidwell <[email protected]> |
[clang] Itanium mangler constructors
The Itanium mangler constructors use both NSDMI and explicit member construction for default values. This is confusing.
*) Use NSDMIs wherever possible
*) Use
[clang] Itanium mangler constructors
The Itanium mangler constructors use both NSDMI and explicit member construction for default values. This is confusing.
*) Use NSDMIs wherever possible
*) Use forwarding ctor for the nesting case with an llvm::raw_null_ostream (and explicitly set NullOut flag in that ctor).
*) Copy the ModuleSubstitutions. This is a bug with no effect in the current mangling, but not in the newer mangling.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119550
show more ...
|
| #
02093906 |
| 14-Feb-2022 |
Nathan Sidwell <[email protected]> |
[clang][NFC] Remove IgnoreLinkageSpecDecls
The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec contexts. It doesn't do this consistently, but there is no need for it to do it at a
[clang][NFC] Remove IgnoreLinkageSpecDecls
The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec contexts. It doesn't do this consistently, but there is no need for it to do it at all. getEffectiveDeclContext never returns a linkage spec, as it either recurses, uses getRedeclContext (which itself removes the specs), or gets the decl context of non-namespace entities.
This patch removes the function and all calls to it. For safety I add a couple of asserts to make sure we never get them.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119748
show more ...
|
| #
815446cd |
| 09-Feb-2022 |
Nathan Sidwell <[email protected]> |
[clang][NFC] Standard substitution checking cleanup
In preparing for module mangling changes I noticed some issues with the way we check for std::basic_string instantiations and friends.
*) there's
[clang][NFC] Standard substitution checking cleanup
In preparing for module mangling changes I noticed some issues with the way we check for std::basic_string instantiations and friends.
*) there's a single routine for std::basic_{i,o,io}stream but it is templatized on the length of the name. Really? just use a StringRef, rather than clone the entire routine just for 'basic_iostream'.
*) We have a helper routine to check for char type, and call it from several places. But given all the instantiations are of the form TPL<char, Other<char> ...> we could just check the first arg is char and the later templated args are instantiating that same type. A simpler type comparison.
*) Because basic_string has a third allocator parameter, it is open coded, which I found a little confusing. But otherwise it's exactly the same pattern as the iostream ones. Just tell that checker about whether there's an expected allocator argument.[*]
*) We may as well return in each block of mangleStandardSubstitution once we determine it is not one of the entities of interest -- it certainly cannot be one of the other kinds of entities.
FWIW this shaves about 500 bytes off the executable.
[*] I suppose we could also have this routine a tri-value, with one to indicat 'it is this name, but it's not the one you're looking for', to avoid later calls trying different names?
Reviewd By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119333
show more ...
|
| #
493c8564 |
| 20-Jan-2022 |
Nathan Sidwell <[email protected]> |
[clang][NFC] Small mangler cleanups
In working on a module mangling problem I noticed a few cleanups to the mangler.
1) Use 'if (auto x = ...' idiom in a couple of places.
2) I noticed both 'isFil
[clang][NFC] Small mangler cleanups
In working on a module mangling problem I noticed a few cleanups to the mangler.
1) Use 'if (auto x = ...' idiom in a couple of places.
2) I noticed both 'isFileContext' and 'isNamespace || isTranslationUnit' synonyms. Let's use the former.
3) The control flow in the seqId mangling was misordered. Let's channel Count von Count. Also fix the inconsistent bracing.
Differential Revision: https://reviews.llvm.org/D117799
show more ...
|
| #
af27466c |
| 20-Dec-2021 |
Sam McCall <[email protected]> |
Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a. Fixed a bad assertion, the target of a UsingShadowDecl must not
Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a. Fixed a bad assertion, the target of a UsingShadowDecl must not have *local* qualifiers, but it can be a typedef whose underlying type is qualified.
show more ...
|
| #
cc56c66f |
| 20-Dec-2021 |
Sam McCall <[email protected]> |
Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.
Breaks sanitizer tests, at least on windows: https://lab.llvm.
Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.
Breaks sanitizer tests, at least on windows: https://lab.llvm.org/buildbot/#/builders/127/builds/21592/steps/4/logs/stdio
show more ...
|