| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 276488
|
| |
|
|
| |
llvm-svn: 276487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teaches FunctionInfo about offsets.
Like the last patch, this one doesn't introduce any visible
functionality change (the core algorithm knows nothing about offsets;
they're just plumbed through). Tests will come when we start acting
differently because of the offsets.
Patch by Jia Chen.
(N.B. I made a tiny change to Jia's patch to avoid warnings by GCC: I
put DenseMapInfo specializations in the `llvm` namespace. Only realized
that those appeared when compiling locally. :) )
Differential Revision: https://reviews.llvm.org/D22634
llvm-svn: 276486
|
| |
|
|
| |
llvm-svn: 276482
|
| |
|
|
| |
llvm-svn: 276481
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang inserts cleanup code before resume similar way as before return instruction.
This makes asan poison local variables causing false use-after-scope reports.
__asan_handle_no_return does not help here as it was executed before
llvm.lifetime.end inserted into resume block.
To avoid false report we need to unpoison stack for resume same way as for return.
PR27453
Reviewers: kcc, eugenis
Differential Revision: https://reviews.llvm.org/D22661
llvm-svn: 276480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adding a flag to diable GVN Hoisting by default.
Note: The GVN Hoist Pass causes some Halide tests to hang. Halide will disable the pass while investigating.
Reviewers: llvm-commits, chandlerc, spop, dberlin
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D22639
llvm-svn: 276479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When vectorizing a tree rooted at a store bundle, we currently try to sort the
stores before building the tree, so that the stores can be vectorized. For other
trees, the order of the root bundle - which determines the order of all other
bundles - is arbitrary. That is bad, since if a leaf bundle of consecutive loads
happens to appear in the wrong order, we will not vectorize it.
This is partially mitigated when the root is a binary operator, by trying to
build a "reversed" tree when that's considered profitable. This patch extends the
workaround we have for binops to trees rooted in a horizontal reduction.
This fixes PR28474.
Differential Revision: https://reviews.llvm.org/D22554
llvm-svn: 276477
|
| |
|
|
| |
llvm-svn: 276476
|
| |
|
|
| |
llvm-svn: 276475
|
| |
|
|
| |
llvm-svn: 276474
|
| |
|
|
| |
llvm-svn: 276472
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22700
llvm-svn: 276471
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds versions of operator + and - which are optimized for the LHS/RHS of the
operator being RValue's. When an RValue is available, we can use its storage space
instead of allocating new space.
On code such as ConstantRange which makes heavy use of APInt's over 64-bits in size,
this results in significant numbers of saved allocations.
Thanks to David Blaikie for all the review and most of the code here.
llvm-svn: 276470
|
| |
|
|
|
|
| |
Just link in the stylesheet from the toplevel dir of the report.
llvm-svn: 276468
|
| |
|
|
|
|
|
| |
The helper will get smarter in a later change, but right now this is
just code reorganization.
llvm-svn: 276467
|
| |
|
|
| |
llvm-svn: 276466
|
| |
|
|
| |
llvm-svn: 276465
|
| |
|
|
| |
llvm-svn: 276464
|
| |
|
|
|
|
|
| |
For some reason this doesn't cause linker errors with MSVC or
clang-cl, but the bots seem to be failing with other compilers.
llvm-svn: 276463
|
| |
|
|
|
|
|
|
|
| |
This adds the actual MachineLegalizeHelper to do the work and a trivial pass
wrapper that legalizes all instructions in a MachineFunction. Currently the
only transformation supported is splitting up a vector G_ADD into one acting on
smaller vectors.
llvm-svn: 276461
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously it was storing all the fields of an msf::Layout as
separate members. This is a trivial cleanup to make it store
an msf::Layout directly. This makes the code more readable
since it becomes clear which fields of PDBFile are actually the
msf specific layout information in a sea of other bookkeeping
fields.
llvm-svn: 276460
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to have the writable and readable PDB
interfaces share code since the read/write and write-only
interfaces now share a single allocator, you don't have to worry
about a builder building a read only interface and then having
the read-only interface's data become corrupt when the builder
goes out of scope. Now the allocator is specified explicitly
to all constructors, so all interfaces can share a single allocator
that is scoped appropriately.
llvm-svn: 276459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides a better layering of responsibilities among different
aspects of PDB writing code. Some of the MSF related code was
contained in CodeView, and some was in PDB prior to this. Further,
we were often saying PDB when we meant MSF, and the two are
actually independent of each other since in theory you can have
other types of data besides PDB data in an MSF. So, this patch
separates the MSF specific code into its own library, with no
dependencies on anything else, and DebugInfoCodeView and
DebugInfoPDB take dependencies on DebugInfoMsf.
llvm-svn: 276458
|
| |
|
|
| |
llvm-svn: 276457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I am getting a bot failure from the thin archive part of this test:
From
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/40468/steps/test_llvm/logs/LLVM%20%3A%3A%20tools__gold__X86__thinlto_emit_linked_objects.ll:
Command Output (stderr):
--
/home/bb/cmake-llvm-x86_64-linux/build/./bin/llvm-ar: creating
/home/bb/cmake-llvm-x86_64-linux/build/test/tools/gold/X86/Output/thinlto_emit_linked_objects.ll.tmp2.a
/usr/bin/ld.gold: internal error in add_writer, at
../../gold/token.h:124
--
This appears to be an issue with an older version of gold. The test case
passes for me locally when I use the gold v1.12 I was testing with, but
when I tried the gold installed on my system which is v1.11 I get the
same error.
Remove the thin archive version of the test, since there isn't a way to
predicate it on gold version.
llvm-svn: 276453
|
| |
|
|
|
|
|
|
|
|
|
| |
Recommiting r275571 after fixing crash reported in PR28270.
Now we erase elements of IOL in deleteDeadInstruction().
Original Summary:
This change use the overlap interval map built from partial overwrite tracking to perform shortening MemIntrinsics.
Add test cases which was missing opportunities before.
llvm-svn: 276452
|
| |
|
|
| |
llvm-svn: 276451
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the distributed backend case, the ThinLink step and the final native
object link are separate processes. This can be problematic when archive
libraries are involved in the link (e.g. via --start-lib/--end-lib
pairs). The linker only includes objects from libraries when
there is a strong reference to them, and depending on the intervening
ThinLTO backend processes' importing/inlining, the strong references
may appear different in the two link steps. See D22356 and D22467
for two scenarios where this causes issues.
To ensure that the final link includes the same objects, this patch
adds support for an "=filename" form of the thinlto-index-only plugin
option, in which case objects gold included in the link are emitted to
the given filename. This should be used as input to the final link (e.g.
via the @filename option to gold), instead of listing all the objects
within --start-lib/--end-lib pairs again.
Note that the support for the gold callback that identifies included
objects was added in gold version 1.12.
Reviewers: davidxl, mehdi_amini
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D22677
llvm-svn: 276450
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22688
llvm-svn: 276449
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address
space.
With this change, these intrinsics are overloaded for any adddress space
for memory objects
and we can use these llvm invariant intrinsics in non-default address
spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant
memory in managed languages.
Reviewers: apilipenko, reames
Subscribers: llvm-commits
llvm-svn: 276447
|
| |
|
|
|
|
|
|
| |
r276409 changed the coverage summary format. Update the script so that
it can parse the new output, and incorporate the new information into
its warnings.
llvm-svn: 276446
|
| |
|
|
|
|
| |
Hexagon backend uses LoopDataPrefetch pass that is defined in Scalar.
llvm-svn: 276441
|
| |
|
|
| |
llvm-svn: 276439
|
| |
|
|
|
|
|
|
|
| |
The size can exceed s_movk_i32's limit, and we don't
want to use it this early since it inhibits optimizations.
This should probably be merged to the release branch.
llvm-svn: 276438
|
| |
|
|
| |
llvm-svn: 276437
|
| |
|
|
|
|
|
| |
Remove dead code from r600 intrinsic removal.
Remove unset members, rename StackSize to be less ambiguous.
llvm-svn: 276436
|
| |
|
|
|
|
|
| |
R600's i1 fp_to_uint selected but was incorrect according to
what instcombine constant folds to.
llvm-svn: 276435
|
| |
|
|
| |
llvm-svn: 276434
|
| |
|
|
| |
llvm-svn: 276433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer scalar/vector types
An extension of D19978, this patch replaces the default BITREVERSE evaluation of individual bit masks+shifts with block mask+shifts when we have integer elements of power-of-2 bits in size.
After calling BSWAP to reverse the order of the constituent bytes (which typically follows a similar approach), every neighbouring 4-bits, 2-bits and finally 1-bit pairs are masked off and swapped over with shifts.
In doing so we can significantly reduce the number of operations required.
Differential Revision: https://reviews.llvm.org/D21578
llvm-svn: 276432
|
| |
|
|
| |
llvm-svn: 276431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows ErrorAsOutParameter to work better with "optional" errors. For
example, consider a function where for certain input values it is known that
the function can't fail. This can now be written as:
Result foo(Arg X, Error *Err) {
ErrorAsOutParameter EAO(Err);
if (<Error Condition>) {
if (Err)
*Err = <report error>;
else
llvm_unreachable("Unexpected failure!");
}
}
Rather than having to construct an ErrorAsOutParameter under every conditional
where Err is known to be non-null.
llvm-svn: 276430
|
| |
|
|
|
|
|
|
|
| |
- FuncNode::findBlock traverses the function every time. Avoid using it,
and keep a cache of block addresses in DataFlowGraph instead.
- The operator[] in the map of definition stacks was very slow. Replace
the map with unordered_map.
llvm-svn: 276429
|
| |
|
|
|
|
|
|
| |
This facilitates code reuse between the builder classes and the
"frozen" read only versions of the classes used for parsing
existing PDB files.
llvm-svn: 276427
|
| |
|
|
|
|
|
|
|
|
| |
This implements support for writing compiland and compiland source
file info to a binary PDB. This is tested by adding support for
dumping these fields from an existing PDB to yaml, reading them
back in, and dumping them again and verifying the values are as
expected.
llvm-svn: 276426
|
| |
|
|
| |
llvm-svn: 276422
|
| |
|
|
| |
llvm-svn: 276419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(reapplied)
As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.
This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.
We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).
Reapplied with fix for PR28657 - removed intrinsic definitions (clang companion patch to be be submitted shortly).
Differential Revision: https://reviews.llvm.org/D22460
llvm-svn: 276416
|
| |
|
|
| |
llvm-svn: 276410
|