COFF sections are accompanied with an auxiliary symbol which includes a
checksum. This checksum used to be filled with just zero but this seems
to upset LINK.exe when it is processing a /INCREMENTAL link job.
Instead, fill the CheckSum field with the JamCRC of the section
contents. This matches MSVC's behavior.
This fixes PR19666.
N.B. A rather simple implementation of JamCRC is given. It implements
a byte-wise calculation using the method given by Sarwate. There are
implementations with higher throughput like slice-by-eight and making
use of PCLMULQDQ. We can switch to one of those techniques if it turns
out to be a significant use of time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246590 91177308-0d34-0410-b5e6-96231b3b80d8
This was last used by the pre-MC object emitter and has been dead for
quite a while. We have better ways to emit endian-dependent stuff now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246571 91177308-0d34-0410-b5e6-96231b3b80d8
This matches the ARM behavior. In both cases, the register is part
of the optional Performance Monitors extension, so, add the feature,
and enable it for the A-class processors we support.
Differential Revision: http://reviews.llvm.org/D12425
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246555 91177308-0d34-0410-b5e6-96231b3b80d8
There are occasions where it is useful to consider the entirety of the
contents of a section. For example, compressed debug info needs the
entire section available before it can compress it and write it out.
The compressed debug info scenario was previously implemented by
mirroring the implementation of writeSectionData in the ELFObjectWriter.
Instead, allow the output stream to be swapped on demand. This lets
callers redirect the output stream to a more convenient location before
it hits the object file.
No functionality change is intended.
Differential Revision: http://reviews.llvm.org/D12509
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246554 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change turns on by default interleaved access vectorization
for AArch64.
We also clean up some tests which were spedifically enabling this
behaviour.
Reviewers: rengolin
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D12149
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246542 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change turns on by default interleaved access vectorization on ARM,
as it has shown to be beneficial on ARM.
Reviewers: rengolin
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D12146
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246541 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Interleaved access lowering removes a memory operation and a
sequence of vector shuffles and replaces it with a series of
memory operations. This should be always beneficial.
This pass in only enabled on ARM/AArch64.
Reviewers: rengolin
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D12145
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246540 91177308-0d34-0410-b5e6-96231b3b80d8
If a symbol is marked as "data", the symbol should be exported
with __imp_ prefix. Previously, the symbol was exported as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246532 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER
value, there's a cmake warning and the build goes on with no
sanitizers at all. This isn't a good behaviour, since cmake warnings
are fairly easy to miss and the resulting behaviour is that it looks
like the build is sanitizer clean.
Upgrade these warnings to errors so misconfigurations are more
obvious.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246531 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM.
1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
executables and shared libraries against libLLVM. For this to work, it
is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.
It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
we also default to OFF in this mode, or tools tend to misbehave (e.g.
stdout may not flush on exit when output is buffered.)
llvm-config and Tablegen do not use libLLVM, as they are dependencies of
libLLVM.
2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
Depending on which one is passed (default is component-libs), we link
with the individual libraries or libLLVM respectively. We pass in dylib
when LLVM_LINK_LLVM_DYLIB is ON.
3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
actually export all. Don't strip leading underscore from symbols on Linux,
and make sure we get all exported symbols and weak-with-default symbols
("W" in nm output). Without these changes, passes won't load because
the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
found.
Testing:
- Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
- Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
never had much success with LLDB tests, and llgoi is currently broken
so check-llgo fails for an unrelated reason.
- Ran "lldb" to ensure it loads.
Reviewers: chandlerc, beanz, pcc, rnk
Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits
Differential Revision: http://reviews.llvm.org/D12488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246527 91177308-0d34-0410-b5e6-96231b3b80d8
These are already added during the MachineInstr construction,
so this was adding the implicit registers twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246525 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, when edge weights are assigned to edges that are created when lowering switch statement, the weight on the edge to default statement (let's call it "default weight" here) is not considered. We need to distribute this weight properly. However, without value profiling, we have no idea how to distribute it. In this patch, I applied the heuristic that this weight is evenly distributed to successors.
For example, given a switch statement with cases 1,2,3,5,10,11,20, and every edge from switch to each successor has weight 10. If there is a binary search tree built to test if n < 10, then its two out-edges will have weight 4x10+10/2 = 45 and 3x10 + 10/2 = 35 respectively (currently they are 40 and 30 without considering the default weight). Each distribution (which is 5 here) will be stored in each SwitchWorkListItem for further distribution.
There are some exceptions:
For a jump table header which doesn't have any edge to default statement, we don't distribute the default weight to it.
For a bit test header which covers a contiguous range and hence has no edges to default statement, we don't distribute the default weight to it.
When the branch checks a single value or a contiguous range with no edge to default statement, we don't distribute the default weight to it.
In other cases, the default weight is evenly distributed to successors.
Differential Revision: http://reviews.llvm.org/D12418
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246522 91177308-0d34-0410-b5e6-96231b3b80d8
Follow LLVM style for the parameter names (`CamelCase` not `camelCase`),
and surface the header docs in doxygen. No functionality change
intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246509 91177308-0d34-0410-b5e6-96231b3b80d8
SETCC is one of those special node types for which operation actions (legality,
etc.) is keyed off of an operand type, not the node's value type. This makes
sense because the value type of a legal SETCC node is determined by its
operands' value type (via the TLI function getSetCCResultType). When the
SDAGBuilder creates SETCC nodes, it either creates them with an MVT::i1 value
type, or directly with the value type provided by TLI.getSetCCResultType.
The first problem being fixed here is that DAGCombine had several places
querying TLI.isOperationLegal on SETCC, but providing the return of
getSetCCResultType, instead of the operand type directly. This does not mean
what the author thought, and "luckily", most in-tree targets have SETCC with
Custom lowering, instead of marking them Legal, so these checks return false
anyway.
The second problem being fixed here is that two of the DAGCombines could create
SETCC nodes with arbitrary (integer) value types; specifically, those that
would simplify:
(setcc a, b, op1) and|or (setcc a, b, op2) -> setcc a, b, op3
(which is possible for some combinations of (op1, op2))
If the operands of the and|or node are actual setcc nodes, then this is not an
issue (because the and|or must share the same type), but, the relevant code in
DAGCombiner::visitANDLike and DAGCombiner::visitORLike actually calls
DAGCombiner::isSetCCEquivalent on each operand, and that function will
recognise setcc-like select_cc nodes with other return types. And, thus, when
creating new SETCC nodes, we need to be careful to respect the value-type
constraint. This is even true before type legalization, because it is quite
possible for the SELECT_CC node to have a legal type that does not happen to
match the corresponding TLI.getSetCCResultType type.
To be explicit, there is nothing that later fixes the value types of SETCC
nodes (if the type is legal, but does not happen to match
TLI.getSetCCResultType). Creating SETCCs with an MVT::i1 value type seems to
work only because, either MVT::i1 is not legal, or it is what
TLI.getSetCCResultType returns if it is legal. Fixing that is a larger change,
however. For the time being, restrict the relevant transformations to produce
only SETCC nodes with a value type matching TLI.getSetCCResultType (or MVT::i1
prior to type legalization).
Fixes PR24636.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246507 91177308-0d34-0410-b5e6-96231b3b80d8
Hopefully this will end the GEPs saga!
This commit reverts r245394, i.e., it reapplies r221876 while incorporating the
fixes from D11847.
r221876 was not reapplied alone because it was not safe and D11847 was not
applied alone because it needs r221876 to produce correct results.
This should fix PR24596.
Original commit message for r221876:
Let's try this again...
This reverts r219432, plus a bug fix.
Description of the bug in r219432 (by Nick):
The bug was using AllPositive to break out of the loop; if the loop break
condition i != e is changed to i != e && AllPositive then the
test_modulo_analysis_with_global test I've added will fail as the Modulo will
be calculated incorrectly (as the last loop iteration is skipped, so Modulo
isn't updated with its Scale).
Nick also adds this comment:
ComputeSignBit is safe to use in loops as it takes into account phi nodes, and
the == EK_ZeroEx check is safe in loops as, no matter how the variable changes
between iterations, zero-extensions will always guarantee a zero sign bit. The
isValueEqualInPotentialCycles check is therefore definitely not needed as all
the variable analysis holds no matter how the variables change between loop
iterations.
And this patch also adds another enhancement to GetLinearExpression - basically
to convert ConstantInts to Offsets (see test_const_eval and
test_const_eval_scaled for the situations this improves).
Original commit message:
This reverts r218944, which reverted r218714, plus a bug fix.
Description of the bug in r218714 (by Nick):
The original patch forgot to check if the Scale in VariableGEPIndex flipped the
sign of the variable. The BasicAA pass iterates over the instructions in the
order they appear in the function, and so BasicAliasAnalysis::aliasGEP is
called with the variable it first comes across as parameter GEP1. Adding a
%reorder label puts the definition of %a after %b so aliasGEP is called with %b
as the first parameter and %a as the second. aliasGEP later calculates that %a
== %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first
parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) -
ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly
conclude that %a > %b.
Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug.
Slightly modified by me to add an early exit from the loop and avoid
unnecessary, but expensive, function calls.
Original commit message:
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code
previously used zext to extend the offset, so negative offsets were converted
to large positive ones.
2. Enhance aliasGEP to deduce that, if the difference between two GEP
allocations is positive and all the variables that govern the offset are also
positive (i.e. the offset is strictly after the higher base pointer), then
locations that fit in the gap between the two base pointers are NoAlias.
Patch by Nick White!
Message from D11847:
Un-revert of r241981 and fix for PR23626. The 'Or' case of GetLinearExpression
delegates to 'Add' if possible, and if not it returns an Opaque value.
Unfortunately the Scale and Offsets weren't being set (and so defaulted to 0) -
and a scale of zero effectively removes the variable from the GEP instruction.
This meant that BasicAA would return MustAliases when it should have been
returning PartialAliases (and PR23626 was an example of the GVN pass using an
incorrect MustAlias to merge loads from what should have been different
pointers).
Differential Revision: http://reviews.llvm.org/D11847
Patch by Nick White <n.j.white@gmail.com>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246502 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This handles all load/store operations that WebAssembly defines, and handles those necessary for C++ such as i1. I left a FIXME for outstanding features which aren't required for now.
Reviewers: sunfish
Subscribers: jfb, llvm-commits, dschuff
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246500 91177308-0d34-0410-b5e6-96231b3b80d8
This was part of D7208 (r227242), but that commit was reverted because it exposed
a bug in AArch64 lowering. I should have that fixed and the rest of the commit
reinstated soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246493 91177308-0d34-0410-b5e6-96231b3b80d8
This would have suppressed bug 24578, about use-after-
destroy on User and MDNode. Rolled back suppression for
the sake of code cleanliness, in preferance for bug
tracking to keep track of this issue.
This reverts commit 6ff2baabc4625d5b0a8dccf76aa0f72d930ea6c0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246484 91177308-0d34-0410-b5e6-96231b3b80d8
DAGCombine has a utility wrapper around TLI's getSetCCResultType; use it in the
one place in DAGCombine still directly calling the TLI function. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246482 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246478 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246476 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246466 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246465 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246463 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246462 91177308-0d34-0410-b5e6-96231b3b80d8
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"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246461 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246459 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246458 91177308-0d34-0410-b5e6-96231b3b80d8
