| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 298722
|
| |
|
|
|
|
|
|
| |
Previously it was added only to the BE.
Differential Revision: https://reviews.llvm.org/D31323
llvm-svn: 298721
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Declarations need to be filtered out when counting functions.
Reviewers: eraman
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31336
llvm-svn: 298720
|
| |
|
|
|
|
| |
around that don't have a constexpr std::pair.
llvm-svn: 298719
|
| |
|
|
|
|
|
|
| |
Patch by Axel Davy (axel.davy@normalesup.org)
Differential revision: https://reviews.llvm.org/D30382
llvm-svn: 298718
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: MSVC does this when producing a PDB.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31316
llvm-svn: 298717
|
| |
|
|
|
|
|
|
| |
SimplifyDemandedUseBits without recursing into ComputeKnownBits
SimplifyDemandedUseBits for Add/Sub already recursed down LHS and RHS for simplifying bits. If that didn't provide any simplifications we fall back to calling computeKnownBits which will recurse again. Instead just take the known bits for LHS and RHS we already have and call into a new function in ValueTracking that can calculate the known bits given the LHS/RHS bits.
llvm-svn: 298711
|
| |
|
|
|
|
|
|
| |
Patch by Axel Davy (axel.davy@normalesup.org)
Differential revision: https://reviews.llvm.org/D30149
llvm-svn: 298710
|
| |
|
|
|
|
|
|
| |
Patch by Axel Davy (axel.davy@normalesup.org)
Differential revision: https://reviews.llvm.org/D30146
llvm-svn: 298708
|
| |
|
|
|
|
|
|
|
|
| |
bits' result, not just comparisons.
Added vector compare opcodes to X86TargetLowering::ComputeNumSignBitsForTargetNode
Covered by existing tests added for D22814.
llvm-svn: 298704
|
| |
|
|
| |
llvm-svn: 298702
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 298701
|
| |
|
|
|
|
|
|
| |
This reverts commit rL298690
Causes failures on clang.
llvm-svn: 298693
|
| |
|
|
|
|
| |
them easier to understand.
llvm-svn: 298692
|
| |
|
|
|
|
| |
create two expressions in symbolic store evaluation.
llvm-svn: 298691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch rL298481 was reverted due to crash on clang-with-lto-ubuntu build.
The reason of the crash was type mismatch between either a or b and RHS in the following situation:
LHS = sext(a +nsw b) > RHS.
This is quite rare, but still possible situation. Normally we need to cast all {a, b, RHS} to their widest type.
But we try to avoid creation of new SCEV that are not constants to avoid initiating recursive analysis that
can take a lot of time and/or cache a bad value for iterations number. To deal with this, in this patch we
reject this case and will not try to analyze it if the type of sum doesn't match with the type of RHS. In this
situation we don't need to create any non-constant SCEVs.
This patch also adds an assertion to the method IsProvedViaContext so that we could fail on it and not
go further into range analysis etc (because in some situations these analyzes succeed even when the passed
arguments have wrong types, what should not normally happen).
The patch also contains a fix for a problem with too narrow scope of the analysis caused by wrong
usage of predicates in recursive invocations.
The regression test on the said failure: test/Analysis/ScalarEvolution/implied-via-addition.ll
llvm-svn: 298690
|
| |
|
|
|
|
| |
of a creating a temporary APInt. NFC
llvm-svn: 298688
|
| |
|
|
|
|
|
| |
due to LLVM's view of phi nodes. It would cause NewGVN not to fixpoint
in some interesting edge cases.
llvm-svn: 298687
|
| |
|
|
|
|
| |
setHighBits/setLowBits/setSignBit. NFCI
llvm-svn: 298683
|
| |
|
|
| |
llvm-svn: 298680
|
| |
|
|
| |
llvm-svn: 298679
|
| |
|
|
|
|
|
|
| |
r298178 capitalized the fields in `ArgListEntry`. All the official
targets were updated accordingly, but as an experimental target AVR
was missed.
llvm-svn: 298677
|
| |
|
|
| |
llvm-svn: 298673
|
| |
|
|
|
|
| |
that size. This will potentially make libFuzzer more sensitive on targets with lots of signals
llvm-svn: 298671
|
| |
|
|
| |
llvm-svn: 298666
|
| |
|
|
| |
llvm-svn: 298665
|
| |
|
|
|
|
|
| |
While fixing a malformed testcase, I discovered that the code
exercised by it was wrong, too.
llvm-svn: 298664
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents crashes when attempting to instrument functions containing
C++ try.
Sanitizer coverage will still fail at runtime when an exception is
thrown through a sancov instrumented function, but that seems marginally
better than what we have now. The full solution is to color the blocks
in LLVM IR and only instrument blocks that have an unambiguous color,
using the appropriate token.
llvm-svn: 298662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For the following CFG:
A->B
B->C
A->C
If there is another edge B->D, then ABC should not be considered as triangle.
Reviewers: davidxl, iteratee
Reviewed By: iteratee
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D31310
llvm-svn: 298661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In DeadArgumentElimination, the call instructions will be replaced. We also need to set the prof weights so that function inlining can find the correct profile.
Reviewers: eraman
Reviewed By: eraman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31143
llvm-svn: 298660
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Library functions can have specific semantics that affect the behavior of
certain passes. DSE, for instance, gives special treatment to malloc-ed pointers
but not to pointers returned from an equivalently typed (but differently named)
function.
MetaRenamer ought not to alter program semantics, so library functions must
remain untouched.
Reviewers: mehdi_amini, majnemer, chandlerc, davide
Reviewed By: davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D31304
llvm-svn: 298659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The current prefix based function layout algorithm only looks at function's entry count, which is not sufficient. A function should be grouped together if its entry count or any call edge count is hot.
Reviewers: davidxl, eraman
Reviewed By: eraman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31225
llvm-svn: 298656
|
| |
|
|
|
|
|
|
|
| |
- Avoid explosive growth of the simplification queue by not queuing
expressions that are alredy in it.
- Add an iteration counter and abort after a sufficiently large number
of iterations (assuming that it's a symptom of an infinite loop).
llvm-svn: 298655
|
| |
|
|
| |
llvm-svn: 298654
|
| |
|
|
|
|
| |
Remove an unused lambda capture that made some bots unhappy.
llvm-svn: 298651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When dumping these records from an object file section, we should use
only one type database. However, when dumping from a PDB, we should use
two: one for the type stream and one for the IPI stream.
Certain type records that normally live in the .debug$T object file
section get moved over to the IPI stream of the PDB file and they get
new indices.
So far, I've noticed that the MSVC linker always moves these records
into IPI:
- LF_FUNC_ID
- LF_MFUNC_ID
- LF_STRING_ID
- LF_SUBSTR_LIST
- LF_BUILDINFO
- LF_UDT_MOD_SRC_LINE
These records have index fields that can point into TPI or IPI. In
particular, LF_SUBSTR_LIST and LF_BUILDINFO point to LF_STRING_ID
records to describe compilation command lines.
I've modified the dumper to have an optional pointer to the item DB, and
to do type name lookup of these fields in that DB. See printItemIndex.
The result is that our pdbdump-headers.test is more faithful to the PDB
contents and the output is less confusing.
Reviewers: ruiu
Subscribers: amccarth, zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D31309
llvm-svn: 298649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old candidate collection method in the outliner caused some very large
regressions in compile time on large tests. For MultiSource/Benchmarks/7zip it
caused a 284.07 s or 1156% increase in compile time. On average, using the
SingleSource/MultiSource tests, it caused an average increase of 8 seconds in
compile time (something like 1000%).
This commit replaces that candidate collection method with a new one which
only visits each node in the tree once. This reduces the worst compile time
increase (still 7zip) to a 0.542 s overhead (22%) and the average compile time
increase on SingleSource and MultiSource to 0.018 s (4%).
llvm-svn: 298648
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
loop unrolling and icp will make the sample profile annotation much harder in the backend. So disable these 2 optimization in the ThinLTO compile phase.
Will add a test in cfe in a separate patch.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: mehdi_amini, llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31217
llvm-svn: 298646
|
| |
|
|
|
|
|
|
| |
reduce the LHS of a sub to 0. This should now be fully handled by SimplifyDemandedInstructionBits now.
Now that we call ShrinkDemandedConstant on the RHS of sub this should be taken care of. This code doesn't trigger on any in tree regressions, but did before ShrinkDemandedConstant was added to the RHS.
llvm-svn: 298644
|
| |
|
|
|
|
|
|
|
|
|
| |
It is not guaranteed that the memory used for MachineBasicBlocks in
the previous MachineFunction hasn't been freed, so holding on to a
pointer to the last function's isn't correct. Particularly I have
observed the sret.ll testcase failing because the first BasicBlock in
the new function happened to be allocated to the exact same memory as
the previously saved and (deleted) PrevInstBB.
llvm-svn: 298642
|
| |
|
|
|
|
|
|
|
| |
Using AssemblyAnnotationWriter for LVI printer prints
for instructions and basic blocks.
So, we explicitly need to print LVI info for the arguments of the function (these
are values and not instructions).
llvm-svn: 298640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The cumulative size of the bitcode files for a very large application
can be huge, particularly with -g. In a distributed build environment,
all of these files must be sent to the remote build node that performs
the thin link step, and this can exceed size limits.
The thin link actually only needs the summary along with a bitcode
symbol table. Until we have a proper bitcode symbol table, simply
stripping the debug metadata results in significant size reduction.
Add support for an option to additionally emit minimized bitcode
modules, just for use in the thin link step, which for now just strips
all debug metadata. I plan to add a cc1 option so this can be invoked
easily during the compile step.
However, care must be taken to ensure that these minimized thin link
bitcode files produce the same index as with the original bitcode files,
as these original bitcode files will be used in the backends.
Specifically:
1) The module hash used for caching is typically produced by hashing the
written bitcode, and we want to include the hash that would correspond
to the original bitcode file. This is because we want to ensure that
changes in the stripped portions affect caching. Added plumbing to emit
the same module hash in the minimized thin link bitcode file.
2) The module paths in the index are constructed from the module ID of
each thin linked bitcode, and typically is automatically generated from
the input file path. This is the path used for finding the modules to
import from, and obviously we need this to point to the original bitcode
files. Added gold-plugin support to take a suffix replacement during the
thin link that is used to override the identifier on the MemoryBufferRef
constructed from the loaded thin link bitcode file. The assumption is
that the build system can specify that the minimized bitcode file has a
name that is similar but uses a different suffix (e.g. out.thinlink.bc
instead of out.o).
Added various tests to ensure that we get identical index files out of
the thin link step.
Reviewers: mehdi_amini, pcc
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31027
llvm-svn: 298638
|
| |
|
|
| |
llvm-svn: 298637
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes pr32329.
Reviewers: spatel, craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31286
llvm-svn: 298633
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Given below case:
%y = shl %x, n
%z = ashr %y, m
when n = m, SCEV models it as sext(trunc(x)). This patch tries to handle
the case where n > m by using sext(mul(trunc(x), 2^(n-m)))) as the SCEV
expression.
llvm-svn: 298631
|
| |
|
|
| |
llvm-svn: 298630
|
| |
|
|
| |
llvm-svn: 298629
|
| |
|
|
|
|
| |
stored on X86TargetLowering.
llvm-svn: 298628
|
| |
|
|
| |
llvm-svn: 298627
|
| |
|
|
|
|
|
|
|
|
| |
Reverting until I can figure out the root cause.
Revert "Re-land: Make NativeExeSymbol a concrete subclass of NativeRawSymbol [PDB]"
This reverts commit f461a70cc376f0f91c8b4917be79479cc86330a5.
llvm-svn: 298626
|