- Jun 03, 2020
-
-
Vedant Kumar authored
Support printing strings which contain invalid utf8 sub-sequences, e.g. strings like "hello world \xfe", instead of bailing out with "Summary Unavailable". I took the opportunity here to delete some hand-rolled utf8 -> utf32 conversion code and replace it with calls into llvm's Support library. rdar://61554346
-
Vedant Kumar authored
The m_size and m_data members of DecodedCharBuffer are meant to be private.
-
Florian Hahn authored
Unconditionally use -verify-machineinstrs and XFAIL the test until fixed.
-
Saleem Abdulrasool authored
The LLVM code base already uses C++14, use std::make_unique to avoid the explicit constructor invocation via new and to avoid spelling out the type twice.
-
Arnold Schwaighofer authored
Summary: For retcon and retcon.once coroutines we assume that all uses of spills can be sunk past coro.begin. This simplifies handling of instructions that escape the address of an alloca. The current implementation would have issues if the address of the alloca is escaped before coro.begin. (It also has issues with casts before and uses of those casts after the coro.begin instruction) %alloca_addr = alloca ... %escape = ptrtoint %alloca_addr coro.begin store %escape to %alloca_addr rdar://60272809 Subscribers: hiraditya, modocache, mgrang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81023
-
Simon Pilgrim authored
-
Florian Hahn authored
The test case highlights a mis-compile reported in PR46105, where a consecutive register list is renamed, which invalidates some other used registers.
-
Florian Hahn authored
Add a new test that checks that metadata is preserved when ssa_copy calls introduced by PredicateInfo are replaced by their original values.
-
Lang Hames authored
Debug sections will not be linked into the final executable and may contain ambiguous relocations*. Skipping them avoids both some unnecessary processing cost and the hassle of dealing with the problematic relocations. * E.g. __debug_ranges contains non-extern relocations to the end of functions hat begin with named symbols. Under the usual rules for interpreting non-extern relocations these will be incorrectly associated with the following block, or no block at all (if there is a gap between one block and the next).
-
Simon Pilgrim authored
-
Richard Smith authored
`...` is rST syntax for hyperlinks etc. ``...`` should be used for code snippets.
-
Steven Wan authored
Summary: This patch changes the AIX default target CPU to power4 since this is the the lowest arch for the lowest OS level supported. Reviewers: hubert.reinterpretcast, cebowleratibm, daltenty Reviewed By: hubert.reinterpretcast Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80835
-
Dorit Nuzman authored
-
jasonliu authored
Without this change, names start with 'L' will get created as temporary symbol in MCContext::createSymbol. Some other potential prefix considered: .L, does not work for AIX, as a function start with L will end up with .L as prefix for its function entry point. ..L could work, but it does not play well with the convention on AIX that anything start with '.' are considered as entry point. L. could work, but not sure if it's safe enough, as it's possible to have suffixes like .something append to a plain L, giving L.something which is not necessarily a temporary. That's why we picked L.. for now. Differential Revision: https://reviews.llvm.org/D80831
-
Hiroshi Yamauchi authored
Reviewers: davidxl Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D81038
-
Louis Dionne authored
-
Richard Smith authored
The absence of a space here caused this codeblock to be missing from the rendered output.
-
Jonas Devlieghere authored
The different tools constructing dotest invocations (lit and lldb-dotest) already print the command invocation so there's no need to print it again in the dotest output. My motivation for removing it is that it doesn't include the Python interpreter and every time I accidentally copy it, the command fails with an `ImportError`. Differential revision: https://reviews.llvm.org/D81032
-
Frederik Gossen authored
Add a new pass to lower operations from the `shape` to the `std` dialect. The conversion applies only to the `size_to_index` and `index_to_size` operations and affected types. Other patterns will be added as needed. Differential Revision: https://reviews.llvm.org/D81091
-
Louis Dionne authored
Libc++ provides support for <thread> in C++03 as an extension. Furthermore, it does not support any compiler that doesn't have rvalue references. It is hence possible to provide the move constructor and move assignment operator in C++03.
-
Paul Pelzl authored
The checker currently supports only a whitelist of block-enumeration methods which are known to internally clear an autorelease pool. Extend this checker to detect writes within the scope of explicit @autoreleasepool statements. rdar://25301111 Differential Revision: https://reviews.llvm.org/D81072
-
Paul Pelzl authored
Idiomatic objc using ARC will generate this expression regularly due to NSError out-param passing. Providing an implementation for this expression allows the analyzer to explore many more codepaths in ARC projects. The current implementation is not perfect but the differences are hopefully subtle enough to not cause much problems. rdar://63918914 Differential Revision: https://reviews.llvm.org/D81071
-
Victor Huang authored
In the function "Analysis.cpp:isInTailCallPosition", it only checks whether a call is in a tail call position if the call has side effects, access memory or it is not safe to speculative execute. Therefore, a speculatable function will not go through tail call position check and improperly tail called when it is not in a tail-call position. This patch enables tail call position check for speculatable functions. Differential Revision: https://reviews.llvm.org/D80661
-
Saleem Abdulrasool authored
ld64 provides the `-search_path_firsts` which will search each path in the library search path order for both `lib[name].dylib`, `lib[name].a` before moving on (searching all paths for the dylib and then falling back to the static library if a shared library was not found). This option has been the default for a long time, but the command line flag still exists. Ignore it for compatibility.
-
David Zarzycki authored
-
Kang Zhang authored
Summary: In the patch D73152, it adds a new function LiveVariables::addNewBlock. This new function will add the reg which PHI used to the MBB which reg is from. But the new function may cause LiveVariable Verification failed when the Src reg in PHI is undef. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D80077
-
Henry Kao authored
Summary: Replaced getVectorNumElements() with getVectorElementCount(). Added operator overloads for class ElementCount. Fixes warning in several AArch64 unit tests. Reviewers: sdesmalen, kmclaughlin, dancgr, efriedma, each, andwar, rengolin Reviewed By: efriedma Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80826
-
Yonghong Song authored
Commit 13f6c81c ("[BPF] simplify zero extension with MOV_32_64") tried to use MOV_32_64 instructions instead of lshift/rshift instructions for zero extension. This has the benefit to remove the number of instructions and may help verifier too. But the same commit also removed the old MOV_32_64 pruning as it deems unsafe as MOV_32_64 does have the side effect, zeroing out the top 32bit in the register. This caused the following failure in kernel selftest test_cls_redirect.o. In linux kernel, we have struct __sk_buff { __u32 data; __u32 data_end; }; The compiler will generate 32bit load for __sk_buff->data and __sk_buff->data_end. But kernel verifier will actually loads an address (64bit address on 64bit kernel) to the result register. In this particular example, the explicit zext was not optimized away and destroyed top 32bit address and the verifier rejected the program : w2 = *(u32 *)(r1 + 76) ... r2 = w2 /* MOV_32_64: this will clear top 32bit */ Currently, if the load and the zext are next to each other, the instruction pattern match can actually capture this to avoid MOV_32_64, e.g., in BPFInstrInfo.td, we have def : Pat<(i64 (zextloadi32 ADDRri:$src)), (SUBREG_TO_REG (i64 0), (LDW32 ADDRri:$src), sub_32)>; However, if they are not next to each other, LDW32 and MOV_32_64 are generated, which may cause the above mentioned problem. BPF Backend already tried to optimize away pattern mov_32_64 + lshift + rshift Commit 13f6c81c may generate mov_32_64 not followed by shifts. This patch added optimization for only mov_32_64 too. Differential Revision: https://reviews.llvm.org/D81048
-
Simon Pilgrim authored
gcc doesn't recognise @llvm.experimental.guard as a code snippet
-
Simon Pilgrim authored
If we're only demanding the (shifted) sign bits of the shift source value, then we can use the value directly. This handles SimplifyDemandedBits/SimplifyMultipleUseDemandedBits for both ISD::SHL and X86ISD::VSHLI. Differential Revision: https://reviews.llvm.org/D80869
-
Yaxun (Sam) Liu authored
Differential Revision: https://reviews.llvm.org/D76795
-
Fangrui Song authored
--no-allow-shlib-undefined (enabled by default when linking an executable) rejects unresolved references in shared objects. Users may be confused by the common diagnostics of unresolved symbols in object files (LLD: "undefined symbol: foo"; GNU ld/gold: "undefined reference to") Learn from GCC/clang " [-Wfoo]": append the option name to the diagnostics. Users can find relevant information by searching "--no-allow-shlib-undefined". It should also be obvious to them that the positive form --allow-shlib-undefined can suppress the error. Also downgrade the error to a warning if --noinhibit-exec is used (compatible with GNU ld and gold). Reviewed By: grimar, psmith Differential Revision: https://reviews.llvm.org/D81028
-
David Tenty authored
Summary: The standard data emission directives (e.g. .short, .long) in the AIX assembler have the unintended consequence of aligning their output to the natural byte boundary. This cause problems because we aren't expecting behavior from the Data*bitsDirectives, so the final alignment of data isn't correct in some cases on AIX. This patch updated the Data*bitsDirectives to use .vbyte pseudo-ops instead to emit the data, since we will emit the .align directives as needed. We update the existing testcases and add a test for emission of struct data. Reviewers: hubert.reinterpretcast, Xiangling_L, jasonliu Reviewed By: hubert.reinterpretcast, jasonliu Subscribers: wuzish, nemanjai, hiraditya, kbarton, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80934
-
Francesco Petrogalli authored
Reviewers: sdesmalen, efriedma Subscribers: tschuett, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80740
-
Matt Arsenault authored
This had multiple functions and only one vague check. Reduce it.
-
David Zarzycki authored
On slow/busy machines, timing cannot be guaranteed.
-
Simon Pilgrim authored
We were bailing on subvector shuffle inputs that were smaller than the subvector type instead of larger than it. Fixes PR46178
-
Nathan James authored
-
Matt Arsenault authored
This is was a very frustrating test to update manually.
-
Louis Dionne authored
The problem mentioned in the XFAILs has been resolved in macosx10.15, so the test is now XPASSing on that platform. rdar://63640184
-