- Feb 18, 2022
-
-
Marek Kurdej authored
Fixes https://github.com/llvm/llvm-project/issues/33336. Reviewed By: HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D120028
-
Louis Dionne authored
Some jobs might not produce those, but it makes the blocks easier to copy-paste and makes sure that if a job does produce an ABI list, it will be updloaded in the artifacts. Differential Revision: https://reviews.llvm.org/D120056
-
Nikolas Klauser authored
Reviewed By: Quuxplusone, ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D119112
-
Casey Carter authored
-
Kadir Cetinkaya authored
Differential Revision: https://reviews.llvm.org/D120065
-
Benjamin Kramer authored
-
Aaron Ballman authored
Now that the AST printer properly handles functions with no parameters in C code, all of the tests relying on AST printing can be updated to use prototypes where appropriate.
-
Mogball authored
NamedAttrList.append(StringAttr, StringAttr) fails to compile because it is matched to the IteratorT append. Fixes the method to only match if the type is an iterator.
-
Fangrui Song authored
The current output section type allows to set the ELF section type to SHT_PROGBITS or SHT_NOLOAD. This patch allows an arbitrary section value to be specified. Some common SHT_* literal names are supported as well. ``` SECTIONS { note (TYPE=SHT_NOTE) : { BYTE(8) *(note) } init_array ( TYPE=14 ) : { QUAD(14) } fini_array (TYPE = SHT_FINI_ARRAY) : { QUAD(15) } } ``` When `sh_type` is specified, it is an error if an input section has a different type. Our syntax is compatible with GNU ld 2.39 (https://sourceware.org/bugzilla/show_bug.cgi?id=28841). Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D118840 -
Philip Reames authored
-
Arthur Eubanks authored
This will bail out on target specific intrinsics. If those are deemed important enough for EarlyCSE to handle, we can augment MemIntrinsicInfo with an access type for TargetTransformInfo::getTgtMemIntrinsic() to handle. Reviewed By: #opaque-pointers, nikic Differential Revision: https://reviews.llvm.org/D120077
-
Fangrui Song authored
The inline `lld::error` expands to two function calls `errorHandler` and `error` where the latter is opaque. Move the functions to .cpp files to decrease code size. My x86-64 lld executable is 9KiB smaller. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120002
-
Snehasish Kumar authored
This reverts commit 9fd2cb21. Fixes an issue on big endian systems where the format version was not converted to little endian prior to passing to GET_VERSION. Differential Revision: https://reviews.llvm.org/D118390
-
Peter Collingbourne authored
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
-
Peter Collingbourne authored
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
-
Joseph Huber authored
This patch adds the '_kmpc_get_hardware_num_threads_in_block' OpenMP RTL function to the externalization RAII struct. This was getting optimized out and then being replaced with an undefined value once added back in, causing bugs for complex reductions. Fixes #53909. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D120076
-
Shafik Yaghmour authored
For the tuple case for the TestStructuredBinding.py the result type is different between libc++ and libstdc++.
-
Alex Brachet authored
Reviewed By: haowei, mcgrathr Differential Revision: https://reviews.llvm.org/D119907
-
Leonard Grey authored
If both an order file and a call graph profile are present, the edges of the call graph which use symbols present in the order file are not used. All of the symbols in the order file will appear at the beginning of the section just as they do currently. In other words, the highest priority derived from the call graph will be below the lowest priority derived from the order file. Practically, this change renames CallGraphSort.{h,cpp} to SectionPriorities.{h,cpp}, and most order file and call graph profile related code is moved into the new file to reduce duplication. Differential Revision: https://reviews.llvm.org/D117354 -
Shafik Yaghmour authored
[DEBUGINFO] [LLDB] Add support for generating debug-info for structured bindings of structs and arrays Currently we are not emitting debug-info for all cases of structured bindings a C++17 feature which allows us to bind names to subobjects in an initializer. A structured binding is represented by a DecompositionDecl AST node and the binding are represented by a BindingDecl. It looks the original implementation only covered the tuple like case which be represented by a DeclRefExpr which contains a VarDecl. If the binding is to a subobject of the struct the binding will contain a MemberExpr and in the case of arrays it will contain an ArraySubscriptExpr. This PR adds support emitting debug-info for the MemberExpr and ArraySubscriptExpr cases as well as llvm and lldb tests for these cases as well as the tuple case. Differential Revision: https://reviews.llvm.org/D119178
-
David Green authored
Also regenerate arm64-neon-2velem-high.ll.
-
Stanislav Mekhanoshin authored
Not clobbered pointer load chains are promoted to global now. That is possible to promote these loads itself into constant address space. Loaded pointers still need to point to global because we need to be able to store into that pointer and because an actual load from it may occur after a clobber. Differential Revision: https://reviews.llvm.org/D119886
-
Benjamin Kramer authored
Same functionality, a lot less code.
-
Zahira Ammarguellat authored
In our downstream, we discovered that the that the .* wildcard in debug-info-hotpatch.cpp (added https://reviews.llvm.org/D116511) ended up matching the entire line on our Windows configurations, causing the -function-padmin check to already be consumed. After digging into it we weren't able to find any sort of reason why the platform would matter here, however we suspect there must be some difference in the regex matcher between systems. This NFC patch replaces the regex with a more conservative regex that prevents this from happening by replacing the . match with an 'everything but double-quote match, [^"]. https://reviews.llvm.org/D120066
-
Dávid Bolvanský authored
LLVM optimizes source codes with mm_malloc better, especially due to alignment info. alloc align https://clang.llvm.org/docs/AttributeReference.html#alloc-align alloc size https://clang.llvm.org/docs/AttributeReference.html#alloc-size Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D117091
-
Nick Desaulniers authored
When building 32b x86 code as PIC, the existing handling of "i" constraints is conservative since generally we have to go through the GOT to find references to functions. But generally, BlockAddresses from C code refer to the Function in the current TU. Permit BlockAddresses to be used with the "i" constraint for those cases. I regressed this in commit 4edb9983 ("[SelectionDAG] treat X constrained labels as i for asm") Fixes: https://github.com/llvm/llvm-project/issues/53868 Reviewed By: efriedma, MaskRay Differential Revision: https://reviews.llvm.org/D119905
-
Aaron Ballman authored
Previously, we would take a declaration like void f(void) and print it as void f(). That's correct in C++ as far as it goes, but is incorrect in C because that converts the function from having a prototype to one which does not. This turns out to matter for some of our tests that use the pretty printer where we'd like to get rid of the K&R prototypes from the test but can't because the test is checking the pretty printed function signature, as done with the ARCMT tests.
-
Johannes Doerfert authored
With https://github.com/llvm/llvm-project/commit/668c5c688be7ab0af37739bbbe2d653be82d5c6f we introduced an ordering issue revealed by the reverse iteration buildbot. Depending on the order of the map that tracks the AAIsDead AAs we ended up with slightly different attributes. This is not totally unexpected and can happen. We should however be deterministic in our orderings to avoid such issues.
-
Kuba Mracek authored
Add a test for VFE where there's several vtables, and one of them contains an invalid entry (from VFE's perspective), and which causes VFE to incorrectly skip scanning subsequent vtables and drop their dependencies.
-
Daniil Suchkov authored
The assertion verifying that a newly computed value matches what is already cached used stripPointerCasts() to strip bitcasts, however the values can be not only pointers, but also vectors of pointers. That is problematic because stripPointerCasts() doesn't handle vectors of pointers. This patch introduces an ad-hoc utility function to strip all bitcasts regardless of the value type. Reviewed By: skatkov, reames Differential Revision: https://reviews.llvm.org/D119994
-
Alex Brachet authored
This reverts commit b9f4dff8.
-
Mike Rice authored
When an a variant is specified that is the same as the base function the compiler will end up crashing in CodeGen. Give an error instead. Differential Revision: https://reviews.llvm.org/D119979
-
Jonas Paulsson authored
Handle multiple memoperands in lowerAlignmentHint(). Review: Ulrich Weigand
-
Alex Brachet authored
Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D120074
-
Artem Dergachev authored
LocationContext::getDecl() isn't useful for obtaining the "farmed" body because the (synthetic) body statement isn't actually attached to the (natural-grown) declaration in the AST. Differential Revision: https://reviews.llvm.org/D119509
-
Arthur Eubanks authored
-
Alexey Bataev authored
-
Philip Reames authored
The code was using exact sizing only, but since what we really need is just to make sure the offsets are in bounds, a minimum bound on the object size is sufficient. To demonstrate the difference, support computing minimum sizes from obects of scalable vector type.
-
Shangwu Yao authored
This patch converts CUDA pointer kernel arguments with default address space to CrossWorkGroup address space (__global in OpenCL). This is because Generic or Function (OpenCL's private) is not supported as storage class for kernel pointer types. Differential Revision: https://reviews.llvm.org/D119207
-
Philip Reames authored
Remove some code which tried to handle the case of comparing two allocas where an object size could not be precisely computed. This code had zero coverage in tree, and at least one nasty bug. The bug comes from the fact that the code uses the size of the result pointer as a proxy for whether the alloca can be of size zero. Since the result of an alloca is *always* a pointer type, and a pointer type can *never* be empty, this check was a nop. As a result, we blindly consider a zero offset from two allocas to never be equal. They can in fact be equal when one or more of the allocas is zero sized. This is particularly ugly because instcombine contains the exact opposite rule. If instcombine reaches the allocas first, it combines them into one (making them equal). If instsimplify reaches the compare first, it would consider them not equal. This creates all kinds of fun scenarios for order of optimization reaching different and contradictory conclusions.
-