| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use to have an odd difference among MapVector and SetVector. The map
used a DenseMop, but the set used a SmallSet, which in turn uses a
std::set.
I have changed SetVector to use a DenseSet. If you were depending on the
old behaviour you can pass an explicit set type or use SmallSetVector.
The common cases for needing to do it are:
* Optimizing for small sets.
* Sets for types not supported by DenseSet.
llvm-svn: 253439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change teaches LLVM's inliner to track and suitably adjust
deoptimization state (tracked via deoptimization operand bundles) as it
inlines through call sites. The operation is described in more detail
in the LangRef changes.
Reviewers: reames, majnemer, chandlerc, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14552
llvm-svn: 253438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.
It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.
There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.
llvm-svn: 253436
|
| |
|
|
| |
llvm-svn: 253432
|
| |
|
|
|
|
| |
Forgot to do this simultaneously with committing the fix.
llvm-svn: 253430
|
| |
|
|
|
|
|
|
|
| |
Most linked executables do not have a symbol table in COFF.
However, it is pretty typical to have some export entries. Use those
entries to inform the disassembler about potential function definitions
and call targets.
llvm-svn: 253429
|
| |
|
|
|
|
| |
CUDA support doesn't reply on temporary patches any more. Thanks Artem!
llvm-svn: 253427
|
| |
|
|
| |
llvm-svn: 253426
|
| |
|
|
| |
llvm-svn: 253425
|
| |
|
|
| |
llvm-svn: 253422
|
| |
|
|
|
|
|
|
| |
This commit is for a later patch that is depend on it. The sum of two
branch probabilities can be greater than 1 due to rounding. It is safer
to saturate the results of sum and subtraction.
llvm-svn: 253421
|
| |
|
|
|
|
| |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68399. Don't need it anyway.
llvm-svn: 253419
|
| |
|
|
|
|
| |
accept a pair of iterators. NFC.
llvm-svn: 253417
|
| |
|
|
|
|
| |
Not ready for merge.
llvm-svn: 253415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
machine block placement.
When looking for the best successor from the outer loop for a block
belonging to an inner loop, the edge probability computation can be
improved so that edges in the inner loop are ignored. For example,
suppose we are building chains for the non-loop part of the following
code, and looking for B1's best successor. Assume the true body is very
hot, then B3 should be the best candidate. However, because of the
existence of the back edge from B1 to B0, the probability from B1 to B3
can be very small, preventing B3 to be its successor. In this patch, when
computing the probability of the edge from B1 to B3, the weight on the
back edge B1->B0 is ignored, so that B1->B3 will have 100% probability.
if (...)
do {
B0;
... // some branches
B1;
} while(...);
else
B2;
B3;
Differential revision: http://reviews.llvm.org/D10825
llvm-svn: 253414
|
| |
|
|
|
|
|
|
|
|
| |
Fix this:
llvm/tools/llvm-profdata/llvm-profdata.cpp:78:15: warning: 12 enumeration values not handled in switch: 'success', 'eof', 'unrecognized_format'... [-Wswitch]
switch (instrError) {
^
llvm-svn: 253413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds MathExtras helper functions for handling unsigned, saturating addition and multiplication. It also updates the instrumentation and sample profile merge implementations to use them.
No functional changes.
Reviewers: dnovillo, bogner, davidxl
Subscribers: davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14720
llvm-svn: 253412
|
| |
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14357
rdar://problem/21942589
llvm-svn: 253411
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
abbreviations via unique_ptr
While still allowing CodeGen/AsmPrinter in llvm to own them using a bump
ptr allocator. (might be nice to replace the pointers there with
something that at least automatically calls their dtors, if that's
necessary/useful, rather than having it done explicitly (I think a typed
BumpPtrAllocator already does this, or maybe a unique_ptr with a custom
deleter, etc))
llvm-svn: 253409
|
| |
|
|
| |
llvm-svn: 253408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic for handling the pattern without a shift is identical
to the logic for handling the pattern with a shift if you set
the shift amount to zero for the former.
This should make it easier to see that we probably don't even need
optimizeIntToFloatBitCast().
If we call something like foldVecTruncToExtElt() from visitTrunc(),
we'll solve PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543
llvm-svn: 253403
|
| |
|
|
|
|
|
|
|
|
|
| |
Missed bit of feedback from D14720.
Show the same "Make sure that all profile
data to be merged is generated from the same binary." hint for hash mismatch
and value site count mismatch as we now do for counter mismatch when merging
incompatible instrumentation profile data.
llvm-svn: 253400
|
| |
|
|
| |
llvm-svn: 253396
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Verified that this was at least /an/ issue, if not the only one, by
initializing NumBuckets to 1 (previously it was uninitialized, so if
this change made a difference, which it did (causing a bunch of tests to
crash) it demonstrates use-of-uninitialized memory). Initializing then
removes the crashes.
Thanks Reid for the debugging assistance
llvm-svn: 253395
|
| |
|
|
|
|
|
| |
Move the data structure defintions out of the namespace. The defs will
be shared by raw format. [NFC]
llvm-svn: 253394
|
| |
|
|
| |
llvm-svn: 253393
|
| |
|
|
|
|
| |
component of the index
llvm-svn: 253392
|
| |
|
|
| |
llvm-svn: 253391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change tries to make the root cause of instrumented profile data merge failures clearer.
Previous:
$ llvm-profdata merge test_0.profraw test_1.profraw -o test_merged.profdata
test_1.profraw: foo: Function count mismatch
test_1.profraw: bar: Function count mismatch
test_1.profraw: baz: Function count mismatch
...
Changed:
$ llvm-profdata merge test_0.profraw test_1.profraw -o test_merged.profdata
test_1.profraw: foo: Function basic block count change detected (counter mismatch)
Make sure that all profile data to be merged is generated from the same binary.
test_1.profraw: bar: Function basic block count change detected (counter mismatch)
test_1.profraw: baz: Function basic block count change detected (counter mismatch)
...
Reviewers: dnovillo, davidxl, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14739
llvm-svn: 253384
|
| |
|
|
| |
llvm-svn: 253379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that there is a one-to-one mapping from MachineFunction to
WinEHFuncInfo, we don't need to use a DenseMap to select the right
WinEHFuncInfo for the current funclet.
The main challenge here is that X86WinEHStatePass is an IR pass that
doesn't have access to the MachineFunction. I gave it its own
WinEHFuncInfo object that it uses to calculate state numbers, which it
then throws away. As long as nobody creates or removes EH pads between
this pass and SDAG construction, we will get the same state numbers.
The other thing X86WinEHStatePass does is to mark the EH registration
node. Instead of communicating which alloca was the registration through
WinEHFuncInfo, I added the llvm.x86.seh.ehregnode intrinsic. This
intrinsic generates no code and simply marks the alloca in use.
Reviewers: JCTremoulet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14668
llvm-svn: 253378
|
| |
|
|
|
|
| |
Also improves .dwo type unit dumping which didn't handle this either.
llvm-svn: 253377
|
| |
|
|
| |
llvm-svn: 253373
|
| |
|
|
|
|
|
|
| |
The instruction combiner previously removed types from filter clauses in Landing Pad instructions if the type had previously been seen in a catch clause. This is incorrect and prevents unexpected exception handlers from rethrowing the caught type.
Differential Revision: http://reviews.llvm.org/D14669
llvm-svn: 253370
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When resolving R_PPC64_REL24, code used to check for an address delta
that fits in 24 bits, while the instructions that take this relocation
actually can process address deltas that fit into *26* bits (as those
instructions have a 24 bit field, but implicitly append two zero bits
at the end since all instruction addresses are a multiple of 4).
This means that code would signal overflow once a single object's text
section exceeds 8 MB, while we can actually support up to 32 MB.
Partially fixes PR25540.
llvm-svn: 253369
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14753
llvm-svn: 253368
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch removes the std::string& argument from a number of C++ LTO API calls
and instead makes them use the installed diagnostic handler. This would also
improve consistency of diagnostic handling infrastructure: if an LTO client used
lto_codegen_set_diagnostic_handler() to install a custom error handler, we do
not want some error messages to go through the custom error handler, and some
other error messages to go into sLastErrorString.
llvm-svn: 253367
|
| |
|
|
| |
llvm-svn: 253366
|
| |
|
|
|
|
|
|
|
| |
While setting function attributes we check all instructions that may access memory. For a call instruction we check all arguments. The special check is required for pointers.
I added vector-of-pointers to the call arguments types that should be checked.
Differential Revision: http://reviews.llvm.org/D14693
llvm-svn: 253363
|
| |
|
|
|
|
| |
No point polluting the header declarations with debugging code.
llvm-svn: 253361
|
| |
|
|
|
|
|
|
| |
Patch by Eugene Kosov!
Differential Revision: http://reviews.llvm.org/D14711
llvm-svn: 253360
|
| |
|
|
| |
llvm-svn: 253359
|
| |
|
|
| |
llvm-svn: 253356
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14728
llvm-svn: 253354
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The underlying issues surrounding codegen for 32-bit vselects have been resolved. The pessimistic costs for 64-bit vselects remain due to the bad
scalarization that is still happening there.
I tested this on A57 in T32, A32 and A64 modes. I saw no regressions, and some improvements.
From my benchmarks, I saw these improvements in A57 (T32)
spec.cpu2000.ref.177_mesa 5.95%
lnt.SingleSource/Benchmarks/Shootout/strcat 12.93%
lnt.MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm-CRC32 11.89%
I also measured A57 A32, A53 T32 and A9 T32 and found no performance regressions. I see much bigger wins in third-party benchmarks with this change
Differential Revision: http://reviews.llvm.org/D14743
llvm-svn: 253349
|
| |
|
|
| |
llvm-svn: 253348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes the behavior of path::system_temp_directory() on Windows to be closer to GetTempPath Windows API call. Enforces path separator to be the native one, makes path absolute, etc. GetTempPath is not used directly because of limitations/implementation bugs on Windows 7.
Windows specific unit tests are added. Most of them runs in separated process with modified environment variables.
This change fixes FileSystemTest.CreateDir unittest that had been failing when run from Unix-like shell on Windows (Unix-like path separator (/) used in env variables).
Reviewers: chapuni, rafael, aaron.ballman
Subscribers: rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D14231
llvm-svn: 253345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SELECT_CC has the nasty property of having operands with unrelated
types. So if you do something like:
f32 = select_cc f16, f16, f32, f32, cc
You'd only look for the action for <select_cc, f32>, but never f16.
If the types are all legal, but the op isn't (as for f16 on AArch64,
or for f128 on x86_64/AArch64?), then you get into trouble.
For f128, we have softenSetCCOperands to handle this case.
Similarly, for f16, we can directly promote the CC operands.
llvm-svn: 253344
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now that setExecutable() changed to do all the ground work to make
memory executable on the host, we can remove all (redundant) calls
to invalidate instruction cache here.
As an added bonus, this makes invalidateInstructionCache() dead
code, so it can be removed.
Differential Revision: http://reviews.llvm.org/D13631
llvm-svn: 253343
|
| |
|
|
|
|
|
|
|
|
| |
setExecutable() should do everything that's needed to make the memory
executable on host, i.e. unconditionally set permissions + invalidate
instruction cache. llvm-rtdyld will be updated in my next commit.
Discusseed with: Lang Hames (as part of D13631).
llvm-svn: 253341
|