| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Ported from AMD builtin library, passes piglit on Turks.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 236647
|
| |
|
|
| |
llvm-svn: 236646
|
| |
|
|
|
|
| |
Contrary to my hopes, it didn't magically work on other platforms.
llvm-svn: 236645
|
| |
|
|
|
|
|
| |
When folding a load in to another instruction, we need to fix the class of the index register
Otherwise, it could be something like GR64 not GR64_NOSP and would fail the machine verifier.
llvm-svn: 236644
|
| |
|
|
| |
llvm-svn: 236643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't create names for temporary symbols when using an object streamer.
The names never make it to the output anyway. From the starting point
of r236629, my heap profile says this drops peak memory usage from 1100
MB to 1058 MB for CodeGen of `verify-uselistorder`, a savings of almost
4% on peak memory, and removes `StringMap<bool, BumpPtrAllocator...>`
from the profile entirely.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 236642
|
| |
|
|
| |
llvm-svn: 236641
|
| |
|
|
|
|
| |
This command dumps a bunch of interesting facts about all Objective-C classes known to LLDB in the inferior process
llvm-svn: 236640
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Aaron Watry <awatry@gmail.com>
Tom Stellard:
- Add denormal handling.
- Share vectorization code with r600 implementation.
Patch By: Aaron Watry
llvm-svn: 236639
|
| |
|
|
| |
llvm-svn: 236638
|
| |
|
|
|
|
|
|
| |
Example usage:
sancov.py print a.out.1234.sancov | sancov.py missing a.out
llvm-svn: 236637
|
| |
|
|
| |
llvm-svn: 236636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's quite possible to encounter an insertvalue instruction that's more deeply
nested than the value we're looking for, but when that happens we really
mustn't compare beyond the end of the index array.
Since I couldn't see any guarantees about what comparisons std::equal makes, we
probably need to directly check the size beforehand. In practice, I suspect
most std::equal implementations would probably bail early, which would be OK.
But just in case...
rdar://20834485
llvm-svn: 236635
|
| |
|
|
|
|
| |
testsuite.
llvm-svn: 236632
|
| |
|
|
|
|
| |
notifications in case of nested regions.
llvm-svn: 236631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
{
signals.set(0);
}
After:
{
signals.set(0);
}
llvm-svn: 236630
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emit the number of bytes in a `.debug_loc` entry directly. The old code
created temp labels (expensive), emitted the difference between them,
and then emitted one on each side of the relevant bytes.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`
(the optimized version of ld64's `-save-temps` when linking the
`verify-uselistorder` executable in an LTO bootstrap). I've hacked
`MCContext::Allocate()` to just call `malloc()` instead of using the
`BumpPtrAllocator` so that the heap profile is easier to read. As far
as peak memory is concerned, `MCContext::Allocate()` is equivalent to a
leak, since it only gets freed at process teardown.
In my heap profile, this patch drops memory usage of
`DwarfDebug::emitDebugLoc()` from 132.56 MB (11.4%) down to 29.86 MB
(2.7%) at peak memory. Some of that must be noise from `SmallVector`
(or other) allocations -- peak memory only dropped from 1160 MB down to
1100 MB -- but this nevertheless shaves 5% off the top.)
llvm-svn: 236629
|
| |
|
|
|
|
|
|
| |
dl_iterate_phdr is somewhat broken in L (see the code for details).
We add runtime OS version detection and fallback to /proc/maps on L or earlier.
This fixes a number of ASan tests on L.
llvm-svn: 236628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This helper function creates a ctor function, which calls sanitizer's
init function with given arguments. This constructor is then expected
to be added to module's ctors. The patch helps unifying how sanitizer
constructor functions are created, and how init functions are called
across all sanitizers.
Reviewers: kcc, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8777
llvm-svn: 236627
|
| |
|
|
| |
llvm-svn: 236626
|
| |
|
|
|
|
| |
specified. Added implicit -w option to disable compilation warnings, in particular to avoid warning on pragma once.
llvm-svn: 236625
|
| |
|
|
| |
llvm-svn: 236624
|
| |
|
|
|
|
| |
barrier.
llvm-svn: 236623
|
| |
|
|
|
|
|
|
|
| |
any type of symbol, which is okay since we are
looking only in the Objective-C module.
<rdar://problem/20828139>
llvm-svn: 236622
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9506
llvm-svn: 236621
|
| |
|
|
| |
llvm-svn: 236620
|
| |
|
|
| |
llvm-svn: 236619
|
| |
|
|
|
|
| |
SelectionDAGBuilder::removeValue is dead now, after rL236563.
llvm-svn: 236618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When computing branch weights in BPI, we used to disallow branches with
weight 0. This is a minor nuisance, because a branch with weight 0 is
different to "don't have information". In the context of
instrumentation, it may mean "never executed", in the context of
sampling, it means "never or seldom executed".
In allowing 0 weight branches, I ran into issues with the switch
expansion code in selection DAG. It is currently hardwired to not handle
branches with weight 0. To maintain the current behaviour, I changed it
to use 1 when it finds 0, but perhaps the algorithm needs changes to
tolerate branches with weight zero.
Reviewers: hansw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9533
llvm-svn: 236617
|
| |
|
|
|
|
| |
regions, barriers + imbalance, loops, single regions reporting.
llvm-svn: 236616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add missing dereferenceable_or_null getters required for
http://reviews.llvm.org/D9253 change. Separated from the D9253 review.
Patch by Artur Pilipenko!
Reviewers: sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9499
llvm-svn: 236615
|
| |
|
|
|
|
|
| |
The @expectedFailureClang decorator was removed in r236447, but it
seems to be fixed only with Clang 3.5+.
llvm-svn: 236614
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The patch disabled unrolling in loop vectorization pass when VF==1 on x86 architecture,
by setting MaxInterleaveFactor to 1. Unrolling in loop vectorization pass may introduce
the cost of overflow check, memory boundary check and extra prologue/epilogue code when
regular unroller will unroll the loop another time. Disable it when VF==1 remove the
unnecessary cost on x86. The same can be done for other platforms after verifying
interleaving/memory bound checking to be not perf critical on those platforms.
Differential Revision: http://reviews.llvm.org/D9515
llvm-svn: 236613
|
| |
|
|
| |
llvm-svn: 236612
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds test to check that when getLazyBitcodeModule is called:
1) Functions are not materailzed by default.
2) Only the requested function gets materialized (if no block addresses
are used).
Reviewers: jvoung, rafael
Reviewed By: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8907
llvm-svn: 236611
|
| |
|
|
| |
llvm-svn: 236610
|
| |
|
|
|
|
|
|
|
|
| |
With neon enabled, we reach SelectBinaryFPOp and are able to get registers for a <2 x double> add.
However, we shouldn't actually attempt arithmetic on it as ARMIselLowering says "v2f64 is legal so that QR subregs can be extracted as f64 elements, but neither Neon nor VFP support any arithmetic operations on it."
This commit disables SelectBinaryFPOp for any vector types. There's already a FIXME to try handle neon. Doing so would require fixing this conditional which isn't safe for vectors 'VT == MVT::f64 || VT == MVT::i64'
llvm-svn: 236609
|
| |
|
|
|
|
|
| |
The new implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.
llvm-svn: 236608
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original
plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all
the work itself. A copy constructor is added to UnwindPlan to enable plan copying.
Test Plan: No regressions on linux test suite.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9369
llvm-svn: 236607
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial code drop for VSX swap optimization permitted the
optimization only when all operations in a web of related computation
are lane-insensitive. For some lane-sensitive operations, we can
still permit the optimization provided that we make adjustments to
those operations. This patch adds special handling for vector splats
so that their presence doesn't kill the optimization.
Vector splats are lane-sensitive since they identify by number a
vector element to be used as the source of a splat. When swap
optimizations take place, the desired vector element will move to the
opposite doubleword of the quadword vector. We thus replace the index
I by (I + N/2) % N, where N is the number of elements in the vector.
A new test case is added to test that swap optimization succeeds when
vector splats are present, and that the proper input element is used
as the source of the splat.
An ancillary change removes SH_BUILDVEC as one of the kinds of special
handling that may be required by VSX swap optimization. From
experience with GCC, I had expected to need some modifications for
vector build operations, but I did not find that to be the case.
llvm-svn: 236606
|
| |
|
|
|
|
|
| |
Fixes PR23428, where std::thread in libstdc++ would go haywire without
these defines.
llvm-svn: 236605
|
| |
|
|
|
|
|
|
|
|
|
| |
E.g.:
default:;
This can be used to get around restrictions as to what can follow a
label. It fixes llvm.org/PR19648.
llvm-svn: 236604
|
| |
|
|
|
|
|
|
| |
the template parameters aren't inside an expression context.
This fixes llvm.org/PR23270.
llvm-svn: 236603
|
| |
|
|
|
|
|
|
| |
before operators.
This fixes llvm.org/23382.
llvm-svn: 236602
|
| |
|
|
| |
llvm-svn: 236601
|
| |
|
|
|
|
| |
It caused undefined behavior.
llvm-svn: 236600
|
| |
|
|
|
|
| |
This fixes llvm.org/PR23397.
llvm-svn: 236599
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
[aaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaa:
aaaaaaaa aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
After:
[aaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaa:aaaaaaaa
aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
Note that this might now violate the column limit and we probably need an
alternative way of indenting these then. However, that is still strictly better
than the messy formatting that clang-format did before.
llvm-svn: 236598
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
[aaaaaaaaaaa
aaaaaaa];
After:
[aaaaaaaaaaa
aaaaaaa];
llvm-svn: 236597
|
| |
|
|
|
|
|
| |
These include paths are leftovers from times when we used GMP or an external
isl installation. They are not longer needed.
llvm-svn: 236596
|