As recently discussed on llvm-dev [1], this patch makes it illegal for
two Functions to point to the same DISubprogram and updates
FunctionCloner to also clone the debug info of a function to conform
to the new requirement. To simplify the implementation it also factors
out the creation of inlineAt locations from the Inliner into a
general-purpose utility in DILocation.
[1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html
<rdar://problem/31926379>
Differential Revision: https://reviews.llvm.org/D32975
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302469 91177308-0d34-0410-b5e6-96231b3b80d8
This is another step towards getting rid of dyn_castNotVal,
so we can recommit:
https://reviews.llvm.org/rL300977
As the tests show, we were missing the lshr case for constants
and both ashr/lshr vector splat folds. The ashr case with constant
was being performed inefficiently in 2 steps. It's also possible
there was a latent bug in that case because we can't do that fold
if the constant is positive:
http://rise4fun.com/Alive/Bge
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302465 91177308-0d34-0410-b5e6-96231b3b80d8
The separated libcalls are implemented in terms of __divmodsi4 and __udivmodsi4
anyway, so we should always use them if possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302462 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
An llvm.dbg.declare of a static alloca is always added to the
MachineFunction dbg variable map, so these values are entirely
redundant. They survive all the way through codegen to be ignored by
DWARF emission.
Effectively revert r113967
Two bugpoint-reduced test cases from 2012 broke as a result of this
change. Despite my best efforts, I haven't been able to rewrite the test
case using dbg.value. I'm not too concerned about the lost coverage
because these were reduced from the test-suite, which we still run.
Reviewers: aprantl, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32920
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302461 91177308-0d34-0410-b5e6-96231b3b80d8
Previously type visitation was done strictly sequentially, and
TypeIndexes were computed by incrementing the TypeIndex of the
last visited record. This works fine for situations like dumping,
but not when you want to visit types in random order. For example,
in a debug session someone might lookup a symbol by name, find that
it has TypeIndex 10,000 and then want to go straight to TypeIndex
10,000.
In order to make this work, the visitation framework needs a mode
where it can plumb TypeIndices through the callback pipeline. This
patch adds such a mode. In doing so, it is necessary to provide
an alternative implementation of TypeDatabase that supports random
access, so that is done as well.
Nothing actually uses these random access capabilities yet, but
this will be done in subsequent patches.
Differential Revision: https://reviews.llvm.org/D32928
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302454 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR32550, in a way that does not imply running the greedy
mode at O0.
The fix consists in checking if a load is used by any floating point
instruction and if yes, we return a default mapping with FPR instead
of GPR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302453 91177308-0d34-0410-b5e6-96231b3b80d8
In r292478, we changed the order of the enum that is referenced by
PMI_FirstXXX. This had the side effect of changing the cost of the
mapping of all the loads, instead of just the FPRs ones.
Reinstate the higher cost for all but GPR loads.
Note: This did not have any external visible effects:
- For Fast mode, the cost would have been higher, but we don't care
because we don't try to use alternative mappings.
- For Greedy mode, the higher cost of the GPR loads, would have
triggered the use of the supposedly alternative mapping, that
would be in fact the same GPR mapping but with a lower cost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302452 91177308-0d34-0410-b5e6-96231b3b80d8
Statistic compile to always be 0 in release build so this compare would always return false. And in the debug builds Statistic are global variables and remember their values across pass runs. So this compare returns true anytime the pass runs after the first time it modifies something.
This was found after reviewing all usages of comparison operators on a Statistic object. We had some internal code that did a compare with a statistic that caused a mismatch in output between debug and release builds. So we did an audit out of paranoia.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302450 91177308-0d34-0410-b5e6-96231b3b80d8
Transforms/IndVarSimplify/2011-10-27-lftrnull will fail if this regresses.
Transforms/GVN/PRE/2011-06-01-NonLocalMemdepMiscompile.ll has been changed to still test what it was
trying to test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302446 91177308-0d34-0410-b5e6-96231b3b80d8
This patch uses KnownOnes of the input of ctlz/cttz to bound the value that can be returned from these intrinsics. This makes these intrinsics more similar to the handling for ctpop which already uses known bits to produce a similar bound.
Differential Revision: https://reviews.llvm.org/D32521
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302444 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces a new interface for computeKnownBits that returns the KnownBits object instead of requiring it to be pre-constructed and passed in by reference.
This is a much more convenient interface as it doesn't require the caller to figure out the BitWidth to pre-construct the object. It's so convenient that I believe we can use this interface to remove the special ComputeSignBit flavor of computeKnownBits.
As a step towards that idea, this patch replaces all of the internal usages of ComputeSignBit with this new interface. As you can see from the patch there were a couple places where we called ComputeSignBit which really called computeKnownBits, and then called computeKnownBits again directly. I've reduced those places to only making one call to computeKnownBits. I bet there are probably external users that do it too.
A future patch will update the external users and remove the ComputeSignBit interface. I'll also working on moving more locations to the KnownBits returning interface for computeKnownBits.
Differential Revision: https://reviews.llvm.org/D32848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302437 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Minor refactoring of foldIdentityShuffles() which allows the removal of a
ConstantDataVector::get() in SimplifyShuffleVectorInstruction.
Reviewers: spatel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32955
Conflicts:
lib/Analysis/InstructionSimplify.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302433 91177308-0d34-0410-b5e6-96231b3b80d8
Currently combineLogicBlendIntoPBLENDV can only match ASHR to detect sign splatting of a bit mask, this patch generalises this to use computeNumSignBits instead.
This is a first step in several things we can do to improve PBLENDV support:
* Better matching of X86ISD::ANDNP patterns.
* Handle floating point cases.
* Better vector and bitcast support in computeNumSignBits.
* Recognise that PBLENDV only uses the sign bit of the mask, we should be able strip away sign splats (ASHR, PCMPGT isNeg tests etc.).
Differential Revision: https://reviews.llvm.org/D32953
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302424 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Following up on Sanjay's suggetion in D32955, move this functionality
into ShuffleVectornstruction.
Reviewers: spatel, RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32956
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302420 91177308-0d34-0410-b5e6-96231b3b80d8
Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool
is explicitly flushed with a .ltorg directive, we should not try
to reference constants in the previous pool any longer, since they
may be out of range.
This fixes assembling hand-written assembler source which repeatedly
loads the same constant value, across a binary size larger than the
pc-relative fixup range for ldr instructions (4096 bytes). Such
assembler source already uses explicit .ltorg instructions to emit
constant pools with regular intervals. However if we try to reuse
constants emitted in earlier pools, they end up out of range.
This makes the output of the testcase match what binutils gas does
(prior to this patch, it would fail to assemble).
Differential Revision: https://reviews.llvm.org/D32847
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302416 91177308-0d34-0410-b5e6-96231b3b80d8
This patch propogates the environment variable SYSTEMDRIVE on Windows when
running the unit tests. This prevents the creation of a directory named
"%SystemDrive%" when running the unit tests from FileSystemTest that use the
function llvm::sys::fs::remove_directories which in turn uses SHFileOperationW.
It is within SHFileOperationW that this environment variable may be used and if
undefined causes the creation of a "%SystemDrive%" directory in the current
directory.
Differential Revision: https://reviews.llvm.org/D32910
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302409 91177308-0d34-0410-b5e6-96231b3b80d8
The value of 'i' is always the smaller of DstParts and SrcParts so we can just use that fact to write all the code in terms of SrcParts and DstParts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302408 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces an LLVM intrinsic and a target opcode for custom event
logging in XRay. Initially, its use case will be to allow users of XRay to log
some type of string ("poor man's printf"). The target opcode compiles to a noop
sled large enough to enable calling through to a runtime-determined relative
function call. At runtime, when X-Ray is enabled, the sled is replaced by
compiler-rt with a trampoline to the logic for creating the custom log entries.
Future patches will implement the compiler-rt parts and clang-side support for
emitting the IR corresponding to this intrinsic.
Reviewers: timshen, dberris
Subscribers: igorb, pelikan, rSerge, timshen, echristo, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D27503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302405 91177308-0d34-0410-b5e6-96231b3b80d8
