| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 373524
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68355
llvm-svn: 373523
|
|
|
|
|
|
|
|
|
|
|
| |
recomputing."
The cause for the revert should be fixed by r373513 /
a80b6c15425f82521c624ff24c5c0a34cd534d54
This reverts commit 47dbcbd8ec6bf6c0b9cbe5811e81a37cc55e73ef.
llvm-svn: 373522
|
|
|
|
|
|
|
|
| |
warnings. NFCI.
The static analyzer is warning about potential null dereferences, but we should be able to use cast<>/castAs<> directly and if not assert will fire for us.
llvm-svn: 373520
|
|
|
|
|
|
|
|
|
|
| |
Store rlwinm Rx, Ry, 32, 0, 31 as rlwinm Rx, Ry, 0, 0, 31 and store
rldicl Rx, Ry, 64, 0 as rldicl Rx, Ry, 0, 0. Otherwise SH field is overflow and
fails assertion in assembly printing stage.
Differential Revision: https://reviews.llvm.org/D66991
llvm-svn: 373519
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
https://reviews.llvm.org/D28596 exposed OnPrint in the global namespace,
which can cause collisions with user-defined OnPrint() functions.
Reviewers: vitalybuka, dvyukov
Reviewed By: vitalybuka, dvyukov
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67987
llvm-svn: 373518
|
|
|
|
|
|
|
|
| |
This commit follows the trend of doing things per-target instead of
modifying the C++ flags globally. It does so for visibility-related
flags, other basic build flags and Windows-specific flags.
llvm-svn: 373517
|
|
|
|
|
|
|
| |
The anonymous namespace starts out (incorrectly) indented but isn't
indented from the TimeRegionsOpt declaration onwards.
llvm-svn: 373516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[MSan] handle llvm.launder.invariant.group
Msan used to give false-positives in
class Foo {
public:
virtual ~Foo() {};
};
// Return true iff *x is set.
bool f1(void **x, bool flag);
Foo* f() {
void *p;
bool found;
found = f1(&p,flag);
if (found) {
// p is always set here.
return static_cast<Foo*>(p); // False positive here.
}
return nullptr;
}
Patch by Ilya Tokar.
Reviewers: #sanitizers, eugenis
Reviewed By: #sanitizers, eugenis
Subscribers: eugenis, Prazek, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68236
llvm-svn: 373515
|
|
|
|
| |
llvm-svn: 373514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Terminators like invoke can have users outside the current basic block.
We have to replace those users with undef, before replacing the
terminator.
This fixes a crash exposed by rL373430.
Reviewers: brzycki, asbirlea, davide, spatel
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D68327
llvm-svn: 373513
|
|
|
|
|
|
|
|
|
|
| |
This is part of a larger shift to move to per-target settings and
eradicate global variables from the CMake build. I'm starting small
with warnings only because those are easy to transition over and I
want to see how it pans out, but we can handle all flags like exceptions
and RTTI in the future.
llvm-svn: 373511
|
|
|
|
|
|
|
|
| |
While around, clean up support for a 8 years old OS.
<rdar://problem/55916729>
llvm-svn: 373510
|
|
|
|
|
|
|
|
| |
This code is only used under __arm64__, use the correct guard.
<rdar://problem/55916729>
llvm-svn: 373509
|
|
|
|
|
|
|
|
|
| |
Another block that's only compiled on __arm64__ and wasn't
updated.
<rdar://problem/55916729>
llvm-svn: 373508
|
|
|
|
|
|
|
|
| |
This didn't show up because nobody built __arm64__ in a while.
<rdar://problem/55916729>
llvm-svn: 373507
|
|
|
|
|
|
|
|
| |
It turns out the benchmarks need to link against those libraries
explicitly too, so CMake's propagation of PUBLIC dependencies is
used.
llvm-svn: 373506
|
|
|
|
|
|
|
|
|
| |
MemoryPhis should be added in the IDF of the blocks newly gaining Defs.
This includes the blocks that gained a Phi and the block gaining a Def,
if the block did not have one before.
Resolves PR43427.
llvm-svn: 373505
|
|
|
|
| |
llvm-svn: 373504
|
|
|
|
| |
llvm-svn: 373503
|
|
|
|
|
|
|
|
| |
Context selectors may include optional score clause in format
`score(<expr>):`, where `<expr>` must be a constant integer expression.
Added parsing/sema analysis only.
llvm-svn: 373502
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the final step in my quest to get rid of the JSON parser
in LLDB. Vedant's coverage report [1] shows that it was mostly untested.
Furthermore, the LLVM implementation has a much nicer API and using it
means one less thing to maintain for LLDB.
[1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html
Differential revision: https://reviews.llvm.org/D68305
llvm-svn: 373501
|
|
|
|
|
|
|
|
|
|
|
| |
GDBRemoteCommunicationServerCommon
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerCommon.
Differential revision: https://reviews.llvm.org/D68304
llvm-svn: 373500
|
|
|
|
|
|
|
|
|
|
|
| |
GDBRemoteCommunicationServerPlatform
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerPlatform.
Differential revision: https://reviews.llvm.org/D68302
llvm-svn: 373499
|
|
|
|
|
|
|
|
|
| |
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationClient.
Differential revision: https://reviews.llvm.org/D68301
llvm-svn: 373498
|
|
|
|
|
|
|
|
|
| |
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerLLGS.
Differential revision: https://reviews.llvm.org/D68299
llvm-svn: 373497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of bits that might be undef
The previous code tried to do a trick where we would extract the subvector from the location we were inserting. Then xor that with the new value. Take the xored value and clear out the bits above the subvector size. Then shift that xored subvector to the insert location. And finally xor that with the original vector. Since the old subvector was used in both xors, this would leave just the new subvector at the inserted location. Since the surrounding bits had been zeroed no other bits of the original vector would be modified.
Unfortunately, if the old subvector came from undef we might aggressively propagate the undef. Then we end up with the XORs not cancelling because they aren't using the same value for the two uses of the old subvector. @bkramer gave me a case that demonstrated this, but we haven't reduced it enough to make it easily readable to see what's happening.
This patch uses a safer, but more costly approach. It isolate the bits above the insertion and bits below the insert point and ORs those together leaving 0 for the insertion location. Then widens the subvector with 0s in the upper bits, shifts it into position with 0s in the lower bits. Then we do another OR.
Differential Revision: https://reviews.llvm.org/D68311
llvm-svn: 373495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sdmitriev, tejohnson
Reviewed by: tejohnson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68318
llvm-svn: 373494
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
64-bit WebAssembly (wasm64) is not specified and not supported in the
WebAssembly backend. We do have support for it in clang, however, and
we would like to keep that support because we expect wasm64 to be
specified and supported in the future. For now add an error when
trying to use wasm64 from the backend to minimize user confusion from
unexplained crashes.
Reviewers: aheejin, dschuff, sunfish
Subscribers: sbc100, jgravelle-google, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68254
llvm-svn: 373493
|
|
|
|
| |
llvm-svn: 373492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend cachepolicy operand in the new VMEM buffer intrinsics
to supply information whether the buffer data is swizzled.
Also, propagate this information to MIR.
Intrinsics updated:
int_amdgcn_raw_buffer_load
int_amdgcn_raw_buffer_load_format
int_amdgcn_raw_buffer_store
int_amdgcn_raw_buffer_store_format
int_amdgcn_raw_tbuffer_load
int_amdgcn_raw_tbuffer_store
int_amdgcn_struct_buffer_load
int_amdgcn_struct_buffer_load_format
int_amdgcn_struct_buffer_store
int_amdgcn_struct_buffer_store_format
int_amdgcn_struct_tbuffer_load
int_amdgcn_struct_tbuffer_store
Furthermore, disable merging of VMEM buffer instructions
in SI Load/Store optimizer, if the "swizzled" bit on the instruction
is on.
The default value of the bit is 0, meaning that data in buffer
is linear and buffer instructions can be merged.
There is no difference in the generated code with this commit.
However, in the future it will be expected that front-ends
use buffer intrinsics with correct "swizzled" bit set.
Reviewers: arsenm, nhaehnle, tpr
Reviewed By: nhaehnle
Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, arphaman, jfb, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68200
llvm-svn: 373491
|
|
|
|
|
|
|
|
| |
This checks finds all primitive type local variables (integers, doubles, pointers) that are declared without an initial value. Includes fixit functionality to initialize said variables with a default value. This is zero for most types and NaN for floating point types. The use of NaNs is copied from the D programming language.
Patch by Jussi Pakkanen.
llvm-svn: 373489
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are no users that pass in LazyValueInfo, so we can simplify the
function a bit.
Reviewers: brzycki, asbirlea, davide
Reviewed By: davide
Differential Revision: https://reviews.llvm.org/D68297
llvm-svn: 373488
|
|
|
|
| |
llvm-svn: 373487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a hole in the handling of devirtualized targets that were
local but need promoting due to devirtualization in another module. We
were not correctly referencing the promoted symbol in some cases. Make
sure the code that updates the name also looks at the ExportedGUIDs set
by utilizing a callback that checks all conditions (the callback
utilized by the internalization/promotion code).
Reviewers: pcc, davidxl, hiraditya
Subscribers: mehdi_amini, Prazek, inglorion, steven_wu, dexonsmith, dang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68159
llvm-svn: 373485
|
|
|
|
|
|
|
|
|
|
| |
As noted on PR41772, the static analyzer reports that the MachineMemOperand::print partial wrappers set a number of args to null pointers that were then dereferenced in the actual implementation.
It turns out that these wrappers are not being used at all (hence why we're not seeing any crashes), so I'd like to propose we just get rid of them.
Differential Revision: https://reviews.llvm.org/D68208
llvm-svn: 373484
|
|
|
|
| |
llvm-svn: 373483
|
|
|
|
|
|
|
|
|
|
| |
Add install targets as necessary to include all files normally installed
in LLVM_DISTRIBUTION_COMPONENTS. This includes targets for Sphinx docs,
opt-viewer Python modules and TableGens.
Differential Revision: https://reviews.llvm.org/D68339
llvm-svn: 373482
|
|
|
|
|
|
|
|
| |
dyn_cast<PHINode> null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<PHINode> directly and if not assert will fire for us.
llvm-svn: 373481
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373480
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: fhahn
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68331
llvm-svn: 373479
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<VectorType> directly and if not assert will fire for us.
llvm-svn: 373478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default is unreachable (PR43129)"
This was reverted in r373454 due to breaking the expensive-checks bot.
This version addresses that by omitting the addSuccessorWithProb() call
when omitting the range check.
> Switch lowering: omit range check for bit tests when default is unreachable (PR43129)
>
> This is modeled after the same functionality for jump tables, which was
> added in r357067.
>
> Differential revision: https://reviews.llvm.org/D68131
llvm-svn: 373477
|
|
|
|
|
|
|
|
|
|
|
|
| |
cycle.
It is possible to craft a .hash section that triggers an infinite loop
in llvm-readelf code. This patch fixes the issue and introduces
a warning.
Differential revision: https://reviews.llvm.org/D68086
llvm-svn: 373476
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373475
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 373474
|
|
|
|
|
|
|
|
|
| |
This is a follow-up for D68085 which allows using "Size"
tag together with "Content" tag or alone.
Differential revision: https://reviews.llvm.org/D68216
llvm-svn: 373473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch disable extraction of the body of the enclosing function.
`void f() [[{}]]`
Extracting this CompoundStmt would leave the enclosing function without
a body.
Reviewers: sammccall, kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68245
llvm-svn: 373472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We weren't always checking if children are RootStmts in ExtractFunction.
For `void f([[int a]]);`, the ParmVarDecl appeared as a RootStmt since
we didn't perform the check and ended up being casted to a (null) Stmt.
Reviewers: sammccall, kadircet
Subscribers: kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68182
llvm-svn: 373471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context.
Without this fix, nested classes can be dumped directly into their CU context if their parent was imported from another CU.
Reviewed By: teemperor, labath
Differential Revision: https://reviews.llvm.org/D68278
Patch by Jaroslav Sevcik!
llvm-svn: 373470
|