| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Also delete and simplify a lot of MachineModuleInfo code that used to be
needed to handle personalities on landingpads. Now that the personality
is on the LLVM Function, we no longer need to track it this way on MMI.
Certainly it should not live on LandingPadInfo.
llvm-svn: 246478
|
| |
|
|
|
|
|
|
| |
Teach FunctionAttr to infer the nonnull attribute on return values of functions which never return a potentially null value. This is done both via a conservative local analysis for the function itself and a optimistic per-SCC analysis. If no function in the SCC returns anything which could be null (other than values from other functions in the SCC), we can conclude no function returned a null pointer. Even if some function within the SCC returns a null pointer, we may be able to locally conclude that some don't.
Differential Revision: http://reviews.llvm.org/D9688
llvm-svn: 246476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example output:
File: <stdin>
Format: Mach-O 64-bit x86-64
Arch: x86_64
AddressSize: 64bit
Dysymtab {
ilocalsym: 0
nlocalsym: 6
iextdefsym: 6
nextdefsym: 2
iundefsym: 8
nundefsym: 0
tocoff: 0
ntoc: 0
modtaboff: 0
nmodtab: 0
extrefsymoff: 0
nextrefsyms: 0
indirectsymoff: 0
nindirectsyms: 0
extreloff: 0
nextrel: 0
locreloff: 0
nlocrel: 0
}
Differential Revision: http://reviews.llvm.org/D12496
llvm-svn: 246474
|
| |
|
|
|
|
|
|
| |
exposing it.
rdar://problem/22491525
llvm-svn: 246472
|
| |
|
|
| |
llvm-svn: 246471
|
| |
|
|
|
|
|
|
| |
Modify msan macros for applying attribute""
This reverts commit 020e70a79878c96457e6882bcdfaf6628baf32b7.
llvm-svn: 246470
|
| |
|
|
|
|
|
|
|
|
| |
This code was dead when it was committed in r23665 (Oct 7, 2005), and before it
reaches its 10th anniversary, it really should go. We can always bring it back
if we'd like, but it forms more SETCC nodes, and the way we do legality
checking on SETCC nodes is wrong in a number of places, and removing this means
fewer places to fix. NFC.
llvm-svn: 246466
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If asked to prove a predicate about a value produced by a PHI node, LazyValueInfo was unable to do so even if the predicate was known to be true for each input to the PHI. This prevented JumpThreading from eliminating a provably redundant branch.
The problematic test case looks something like this:
ListNode *p = ...;
while (p != null) {
if (!p) return;
x = g->x; // unrelated
p = p->next
}
The null check at the top of the loop is redundant since the value of 'p' is null checked on entry to the loop and before executing the backedge. This resulted in us a) executing an extra null check per iteration and b) not being able to LICM unrelated loads after the check since we couldn't prove they would execute or that their dereferenceability wasn't effected by the null check on the first iteration.
Differential Revision: http://reviews.llvm.org/D12383
llvm-svn: 246465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on comments from Hal
(http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150810/292978.html),
I've changed the interface to add a callback mechanism to the
TargetFrameLowering class to query whether the specific target
supports shrink wrapping. By default, shrink wrapping is disabled by
default. Each target can override the default behaviour using the
TargetFrameLowering::targetSupportsShrinkWrapping() method. Shrink
wrapping can still be explicitly enabled or disabled from the command
line, using the existing -enable-shrink-wrap=<true|false> option.
Phabricator: http://reviews.llvm.org/D12293
llvm-svn: 246463
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The ISelLowering code turned insertion turned the element for the
lowest lane of a BUILD_VECTOR into an INSERT_SUBREG, this prohibited
the patterns for SCALAR_TO_VECTOR(Load) to match later. Restrict this
to cases without a load argument.
Reported in rdar://22223823
Differential Revision: http://reviews.llvm.org/D12467
llvm-svn: 246462
|
| |
|
|
|
|
|
|
|
| |
X86FastISel has been using the wrong register class for VBLENDVPS which
produces a VR128 and needs an extra copy to the target register. The
problem was already hit by the existing test cases when using
> llvm-lit -Dllc="llc -verify-machineinstr"
llvm-svn: 246461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Constant vectors weren't allowed to have an i1 condition in the
BitcodeReader. Make sure we have the same restrictions that are
documented, not more.
Reviewers: nlewycky, rafael, kschimpf
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12440
llvm-svn: 246459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This CL is associated with a fuzzing effort to find bugs in LLVM. The
first step is to fuzz llvm-as to find potential issues in generating
IR. Both afl-fuzz and LLVM's lib/Fuzzer are being used.
This CL introduces the executable that implements the in-process
fuzzer using LLVM's lib/Fuzzer. The motivation for using lib/Fuzzer is
based on time comparisons between afl-fuzz and lib/Fuzzer. Early
results show that per-process, the lib/Fuzzer implemenation of llvm-as
(i.e. this CL) generates over 30 times the number of mutations found
by afl-fuzz, per hour runtime. The speedup is due to the removal of
overhead of forking a process, and loading the executable into memory.
I placed this under the tools directory, since it is an executable. It
is also only conditionally built if (using cmake) the flag
LLVM_USEE_SANITIZE_COVERAGE is used, so that it isn't built by
default.
Reviewers: kcc, filcab
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12438
llvm-svn: 246458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid marking some MCSymbols as used in MC/AsmParser.cpp when no uses
exist. This fixes a bug in parseAssignmentExpression() which
inadvertently sets IsUsed, thereby triggering:
"invalid re-assignment of non-absolute variable"
on otherwise valid code. No other functionality change intended.
The original version of this patch touched many calls to MCSymbol
accessors. On rafael's advice, I have stripped this patch down a bit.
As a follow-up, I intend to find the call sites which intentionally set
IsUsed and force them to do so explicitly.
Differential Revision: http://reviews.llvm.org/D12347
llvm-svn: 246457
|
| |
|
|
|
|
| |
This fixes a regression introduced in r246151.
llvm-svn: 246453
|
| |
|
|
| |
llvm-svn: 246451
|
| |
|
|
|
|
|
|
| |
attribute"
This reverts commit 5e3bfbb38eb3fb6f568b107f6b239e0aa4c5f334.
llvm-svn: 246450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to repress sanitization. Move attribute for repressing sanitization to
operator delete for User, MDNode.
Summary: In response to bug 24578, reported against failing LLVM test.
Reviewers: chandlerc, rsmith, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12335
llvm-svn: 246449
|
| |
|
|
| |
llvm-svn: 246440
|
| |
|
|
|
|
|
|
| |
Added tests for encoding.
Differential Revision: http://reviews.llvm.org/D11979
llvm-svn: 246439
|
| |
|
|
|
|
|
|
| |
Added tests for intrinsics and encoding.
Differential Revision: http://reviews.llvm.org/D12491
llvm-svn: 246436
|
| |
|
|
|
|
|
|
| |
Added tests for encoding.
Differential Revision: http://reviews.llvm.org/D11973
llvm-svn: 246432
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11941
llvm-svn: 246431
|
| |
|
|
|
|
|
|
| |
Added tests for intrinsics and encoding.
Differential Revision: http://reviews.llvm.org/D12270
llvm-svn: 246428
|
| |
|
|
|
|
|
|
|
| |
AggressiveAntiDepBreaker was doing some EarlyClobber checking, but was not
checking that the register being potentially renamed was defined by an
early-clobber def where there was also a use, in that instruction, of the
register being considered as the target of the rename. Fixes PR24014.
llvm-svn: 246423
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If run with other locales (like French),
the decode operation might fail
Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D12432
llvm-svn: 246421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
JumpThreading shouldn't duplicate a convergent call, because that would move a convergent call into a control-inequivalent location. For example,
if (cond) {
...
} else {
...
}
convergent_call();
if (cond) {
...
} else {
...
}
should not be optimized to
if (cond) {
...
convergent_call();
...
} else {
...
convergent_call();
...
}
Test Plan: test/Transforms/JumpThreading/basic.ll
Patch by Xuetian Weng.
Reviewers: resistor, arsenm, jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12484
llvm-svn: 246415
|
| |
|
|
|
|
| |
isn't found.
llvm-svn: 246412
|
| |
|
|
|
|
|
|
| |
This testcase required 2 copies of the same file, and the second
copy was missing. It was currently working because of a bug I'm
about to fix.
llvm-svn: 246411
|
| |
|
|
|
|
|
|
|
|
| |
The fix is trivial (The actual patch is 2 lines, but as it changes
indentation it looks like more).
clang does not produce this kind of (slightly bogus) debug info
anymore, thus I had to rely on a hand-crafted assembly test to trigger
that case.
llvm-svn: 246410
|
| |
|
|
|
|
|
| |
The current range cache will will just be hit more often, no
visible external change.
llvm-svn: 246409
|
| |
|
|
|
|
|
|
|
| |
The value of an inlined subprogram low_pc attribute should not
get relocated, but it can happen that it matches the enclosing
function's start address and thus gets the generic treatment.
Special case it to avoid applying the PC offset twice.
llvm-svn: 246406
|
| |
|
|
| |
llvm-svn: 246404
|
| |
|
|
|
|
|
| |
This option dumps the STAB entries that define the debug map(s)
stored in the input binaries, and then exits.
llvm-svn: 246403
|
| |
|
|
|
|
|
|
| |
Specifically, the header now provides llvm::thread, which is either a
typedef of std::thread or a replacement that calls the function synchronously
depending on the value of LLVM_ENABLE_THREADS.
llvm-svn: 246402
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were really two problems here. The first was that we had the truth tables
for signed i1 comparisons backward. I imagine these are not very common, but if
you have:
setcc i1 x, y, LT
this has the '0 1' and the '1 0' results flipped compared to:
setcc i1 x, y, ULT
because, in the signed case, '1 0' is really '-1 0', and the answer is not the
same as in the unsigned case.
The second problem was that we did not have patterns (at all) for the unsigned
comparisons select_cc nodes for i1 comparison operands. This was the specific
cause of PR24552. These had to be added (and a missing Altivec promotion added
as well) to make sure these function for all types. I've added a bunch more
test cases for these patterns, and there are a few FIXMEs in the test case
regarding code-quality.
Fixes PR24552.
llvm-svn: 246400
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12478
llvm-svn: 246381
|
| |
|
|
|
|
|
|
|
| |
*getSplatValue(Value *Val);""
This reverts commit r246379. It seems that the commit was not the culprit,
and the bot will be investigated for instability.
llvm-svn: 246380
|
| |
|
|
|
|
|
|
|
|
| |
*getSplatValue(Value *Val);"
This reverts commit r246371, as it cause a rather obscure bug in AArch64
test-suite paq8p (time outs, seg-faults). I'll investigate it before
reapplying.
llvm-svn: 246379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
architecture string is something quite weird. Similarly delay calling
the BPF parsing code, although that is more reasonable.
To understand why I was motivated to make this change, it cuts the time
for running the ADT TripleTest unittests by a factor of two in
non-optimized builds (the developer default) and reduces my 'check-llvm'
time by a full 15 seconds. The implementation of parseARMArch is *that*
slow. I tried to fix it in the prior series of commits, but frankly,
I have no idea how to finish fixing it. The entire premise of the
function (to allow 'v7a-unknown-linux' or some such to parse as an
'arm-unknown-linux' triple) seems completely insane to me, but I'll let
the ARM folks sort that out. At least it is now out of the critical path
of every developer working on LLVM. It also will likely make some other
folks' code significantly faster as I've heard reports of 2% of time
spent in triple parsing even in optimized builds!
I'm not done making this code faster, but I am done trying to improve
the ARM target parsing code.
llvm-svn: 246378
|
| |
|
|
|
|
| |
expanding the .def file within a StringSwitch.
llvm-svn: 246377
|
| |
|
|
|
|
|
|
|
| |
getSerializable*MachineOperandTargetFlags
Make the arrays 'static const' instead of just 'static'. Post-commit review
comment from Roman Divacky on IRC. NFC.
llvm-svn: 246376
|
| |
|
|
|
|
|
|
|
|
| |
of its strings when expanding the string literals from the macros, and
push all of the APIs to be StringRef instead of C-string APIs.
This (remarkably) removes a very non-trivial number of strlen calls. It
even deletes code and complexity from one of the primary users -- Clang.
llvm-svn: 246374
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for MIR serialization of PowerPC-specific operand target flags
(based on the generic infrastructure added in r244185 and r245383).
I won't even pretend that this is good test coverage, but this includes the
regression test associated with r246372. Adding an MIR test for that fix is far
superior to adding an IR-level test because particular instruction-scheduling
decisions are necessary in order to expose the bug, and using an MIR test we
can start the pipeline post-scheduling.
llvm-svn: 246373
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Even through ADDISdtprelHA generally has r3 as its source register, it is
possible for the instruction scheduler to move things around such that some
other register is the source. We need to print the actual source register, not
always r3. Fixes PR24394.
The test case will come in a follow-up commit because it depends on MIR
target-flags parsing.
llvm-svn: 246372
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Value *getSplatValue(Value *Val);
It complements the CreateVectorSplat(), which creates 2 instructions - insertelement and shuffle with all-zero mask.
The new function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr).
It also returns a splat value form ConstantDataVector, for completeness.
Differential Revision: http://reviews.llvm.org/D11124
llvm-svn: 246371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the necessary tables.
This will allow me to restructure the code and structures using this to
be significantly more efficient. It also removes the duplication of the
list of several enumerators. It also enshrines that the order of
enumerators match the order of the entries in the tables, something the
implementation code actually uses.
No functionality changed (yet).
llvm-svn: 246370
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
parsing logic prior to making substantial changes to it.
This parsing logic is incredibly wasteful, so I'm planning to rewrite
it. Just unittesting the triple parsing logic spends well over 80% of
its time in the ARM parsing logic, and others have measured significant
time spent here in real production compiles.
Stay tuned...
llvm-svn: 246369
|
| |
|
|
|
|
|
| |
the namespace that we are already using for the enums that are produced
by the parsing.
llvm-svn: 246367
|
| |
|
|
|
|
| |
Identical to SELECT, just with different operand numbers.
llvm-svn: 246366
|