- Aug 10, 2021
-
-
Raphael Isemann authored
-
Raphael Isemann authored
-
Thomas Preud'homme authored
Explicitely set x86_64-linux-gnu as a target for asan-use-callbacks clang test since some target do not support -fsanitize=address (e.g. i386-pc-openbsd). Also remove redundant -fsanitize=address and move -emit-llvm right after -S. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107633
-
David Sherwood authored
I have added RUN lines to both: Transforms/LoopVectorize/AArch64/strict-fadd.ll Transforms/LoopVectorize/AArch64/scalable-strict-fadd.ll to show the default behaviour is to not vectorise when the following flag is unset: -force-ordered-reductions
-
Brian Cain authored
-
Florian Mayer authored
This reverts commit ba06ac8b.
-
Sam McCall authored
Before this patch, CXXCtorInitializers that don't typecheck get discarded in most cases. In particular: - typos that can't be corrected don't turn into RecoveryExpr. The full expr disappears instead, and without an init expr we discard the node. - initializers that fail initialization (e.g. constructor overload resolution) are discarded too. This patch addresses both these issues (a bit clunkily and repetitively, for member/base/delegating initializers) It does not preserve any AST nodes when the member/base can't be resolved or other problems of that nature. That breaks invariants of CXXCtorInitializer itself, and we don't have a "weak" RecoveryCtorInitializer like we do for Expr. I believe the changes to diagnostics in existing tests are improvements. (We're able to do some analysis on the non-broken parts of the initializer) Differential Revision: https://reviews.llvm.org/D101641
-
Sam McCall authored
Similar to ad2d6bbb Differential Revision: https://reviews.llvm.org/D107693
-
Raphael Isemann authored
LLDB evaluates some utility expression to update the Objective-C class list that ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`. This adds a test that just tries to define our own bogus version of `objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we currently don't have a way to tell LLDB to look for the function in a specific library. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D107778
-
Raphael Isemann authored
[lldb] Add a test for potentially conflicting names for the Objective-C class update utility expression We recently had an issue where a user declared a `Class::free` function which then got picked up by accident by the expression evaluator when calling `::free`. This was due to a too lax filter in the DWARFIndex (which was fixed by https://reviews.llvm.org/D73191 ). This broke the Objective-C utility expression that is trying to update the Objective-C class list (which is calling `:;free`). This adds a regression test for situations where we have a bunch of functions defined that share the name of the global functions that this utility function calls. None of them are actually conflicting with the global functions we are trying to call (they are all in namespaces, objects or classes). Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D107776
-
David Green authored
This was checking extends as shuffles, where as we should be checking the operands. This helps sink the shuffles, creating more addl/subl instructions. Differential Revision: https://reviews.llvm.org/D107623
-
David Green authored
-
Tim Northover authored
-
Florian Mayer authored
Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D107816
-
Sven van Haastregt authored
Align guards of these builtins with opencl-c.h.
-
Konstantin Schwarz authored
If a G_SHL is fed by a G_CONSTANT, the lower and upper bits of the source can be shifted individually by the constant shift amount. However in case the shift amount came from a G_TRUNC(G_CONSTANT), the generic shift legalization code was used, producing intermediate shifts that are potentially illegal on some targets. This change teaches narrowScalarShift to look through G_TRUNCs and G_*EXTs. Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D89100
-
bakhtiyar authored
Reviewed By: ezhulenev Differential Revision: https://reviews.llvm.org/D107788
-
Lang Hames authored
rdar://81056700
-
Lang Hames authored
Darwin/MachO TLV support was only getting built into the x86_64 slice, not the x86_64h slice. This caused errors when using the ORC runtime on Haswell machines. rdar://81056700
-
Jean Perier authored
https://reviews.llvm.org/D105464 did not correctly cover the case where the symbol from the host procedure is use associated. Outside of the mis-parsed ArrayRef case, flang was also creating a symbol with HostAssociated details inside the internal procedure (pointing to the use associated symbol in the host). That is what lowering expects. This patch ensures the same logic is applied in the mis-parsed array-ref name resolution (and the pointer target name resolution). Differential Revision: https://reviews.llvm.org/D107759
-
Carl Ritson authored
Avoid stack overflow errors on systems with small stack sizes by removing recursion in FoldCondBranchOnPHI. This is a simple change as the recursion was only iteratively calling the function again on the same arguments. Ideally this would be compiled to a tail call, but there is no guarantee. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D107803
-
Fraser Cormack authored
This patch aims to clear up any confusion in documentation for the fadd/fmul reduction creation APIs with regards to the sequential and unordered variations without changing the APIs themselves. The scalar accumulator value isn't only used for sequential reduction intrinsics so the impliciation to the contrary was dropped. Then I thought it useful to make clear that the API always creates a sequential reduction. And lastly a note to users on how it is possible to transform the resulting reduction into an unordered one. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D107753
-
Ben Dunbobbin authored
We had coverage of empty archive in our downstream testsuite. This adds those cases upstream. Differential Revision: https://reviews.llvm.org/D107471
-
Ben Dunbobbin authored
This adds thin archives to the map file test. I noticed that we had this test-case in our downstream testsuite but it wasn't in the upstream testing. Differential revision: https://reviews.llvm.org/D107555
-
Archibald Elliott authored
D105263 introduced this new test. It fails when asserts are disabled, due to using a debug option on opt. Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D107805
-
David Green authored
This changes a couple of calls to LiveRegs.contains to !LiveRegs.available, one in Thumb1FrameLoweringInfo (which modifies a test to look more correct to me, given r7 should be the frame pointer so is not available), and another in the ARMLoadStoreOptimizer, that I don't have a test for, it was just found by inspection. Differential Revision: https://reviews.llvm.org/D107454
-
Tony Tye authored
C++20 no longer requires the failure memory ordering to be no stronger than the success memory ordering. Adjust assert in AMD GPU SIMemoryLegalizer, and merge instruction memory orderings Add common operation to merge memory orders that allows non strict memory orderings to be combined. Use it in SIMemoryLegalizer and MachineMemOperand::getMergedOrdering. Reviewed By: efriedma, rampitec Differential Revision: https://reviews.llvm.org/D106729
-
Florian Mayer authored
We would put the return address there, rather than the fault address. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D107578
-
David Sherwood authored
I have updated cheapToScalarize to also consider the case when extracting lanes from a stepvector intrinsic. This required removing the existing 'bool IsConstantExtractIndex' and passing in the actual index as a Value instead. We do this because we need to know if the index is <= known minimum number of elements returned by the stepvector intrinsic. Effectively, when extracting lane X from a stepvector we know the value returned is also X. New tests added here: Transforms/InstCombine/vscale_extractelement.ll Differential Revision: https://reviews.llvm.org/D106358
-
Vitaly Buka authored
-
Vitaly Buka authored
Without interceptor implementation may call strlen on internal buffers causing false msan errors. Differential Revision: https://reviews.llvm.org/D107615
-
Martin Storsjö authored
This one already had a proper explanation why it fails, which is due to differences by design in MSVC mode. This isn't a fixme, so degrade the annotation to a more permanent "XFAIL: msvc" instead. Differential Revision: https://reviews.llvm.org/D107758
-
Martin Storsjö authored
Such environments do have aligned allocation functions these days, but the RTTI type name test needs to be adjusted for the MSVC C++ ABI. Differential Revision: https://reviews.llvm.org/D107757
-
Martin Storsjö authored
This allows waiving the right amount of asserts on Windows and zOS. This should supersede D107124 and D105910. Differential Revision: https://reviews.llvm.org/D107755
-
Cullen Rhodes authored
Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D107752
-
David Sherwood authored
This patch updates ConstantVector::getSplat to use poison instead of undef when using insertelement/shufflevector to splat. This follows on from D93793. Differential Revision: https://reviews.llvm.org/D107751
-
Tres Popp authored
Replace some code snippets With scf::ForOp methods. Additionally, share a listener at one more point (although this pattern is still not safe to roll back currently) Differential Revision: https://reviews.llvm.org/D107754
-
LLVM GN Syncbot authored
-
Wang, Pengfei authored
1. Enable FP16 type support and basic declarations used by following patches. 2. Enable new instructions VMOVW and VMOVSH. Ref.: https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D105263
-
Fangrui Song authored
Reviewed By: benshi001, mhjacobson Differential Revision: https://reviews.llvm.org/D107797
-