| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
compile errors
llvm-svn: 294578
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.
Differential Revision: https://reviews.llvm.org/D29637
llvm-svn: 294577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions [NFC]
During SCoP construction we sometimes inspect the underlying IR by looking at
the base address of a MemoryAccess. In such cases, we always want the original
base address. Make this clear by calling getOriginalBaseAddr().
This is a non-functional change as getBaseAddr maps to getOriginalBaseAddr
at the moment.
This change removes unnecessary uses of MemoryAddress::getBaseAddr() in
preparation for https://reviews.llvm.org/D28518.
llvm-svn: 294576
|
| |
|
|
|
|
|
|
|
| |
The base address of a memory access is already an llvm::Value. Hence, there is
no need to go through SCEV, but we can directly work with the llvm::Value.
Also use 'Value *' instead of 'auto' for cases where the type is not obvious.
llvm-svn: 294575
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of iterating over statements and their memory accesses to extract the
set of available base pointers, just directly iterate over all ScopArray
objects. This reflects more the actual intend of the code: collect all arrays
(and their base pointers) to emit alias information that specifies that accesses
to different arrays cannot alias.
This change removes unnecessary uses of MemoryAddress::getBaseAddr() in
preparation for https://reviews.llvm.org/D28518.
llvm-svn: 294574
|
| |
|
|
|
|
|
|
|
|
| |
Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.
Differential revision: https://reviews.llvm.org/D29630
Reviewers: EricWF, joerg
llvm-svn: 294573
|
| |
|
|
|
|
| |
BlockValueStack can be reallocated making reference e invalid.
llvm-svn: 294572
|
| |
|
|
|
|
|
|
| |
There are problems with using the machine information to derive the precise
vector size on polly-amd64-linux and polly-arm-linux. We temporarily disable
the problematic run lines.
llvm-svn: 294571
|
| |
|
|
| |
llvm-svn: 294570
|
| |
|
|
|
|
| |
size.
llvm-svn: 294569
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change we used the name of the base pointer to mark reductions. This
is imprecise as the canonical reference is the ScopArray itself and not the
basepointer of a reduction. Using the base pointer of reductions is problematic
in cases where a single ScopArray is referenced through two different base
pointers.
This change removes unnecessary uses of MemoryAddress::getBaseAddr() in
preparation for https://reviews.llvm.org/D28518.
llvm-svn: 294568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When computing reduction dependences we first identify all ScopArrays which are
part of reductions and then only compute for these ScopArrays the more detailed
data dependences that allow us to identify reductions and optimize across them.
Instead of using the base pointer as identifier of a ScopArray, it is clearer
and more understandable to directly use the ScopArray as identifier. This change
implements such a switch.
This change removes unnecessary uses of MemoryAddress::getBaseAddr() in
preparation for https://reviews.llvm.org/D28518.
llvm-svn: 294567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When regenerating code in the BlockGenerator we copy instructions that may
references scalar values, for which the new value of a given scalar is looked up
in BBMap using the original scalar llvm::Value as index. It is consequently
necessary that (re)loaded scalar values are made available in BBMap using the
original llvm::Value as key independently if the llvm::Value was (re)loaded from
the original scalar or a new access function has been specified that caused the
value to be reloaded from an array with a differnet base address. We make this
clear by using MemoryAccess::getOriginalBaseAddr() instead of
MemoryAccess::getBaseAddr() as index to BBMap.
This change removes unnecessary uses of MemoryAddress::getBaseAddr() in
preparation for https://reviews.llvm.org/D28518.
llvm-svn: 294566
|
| |
|
|
| |
llvm-svn: 294565
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimization
Isolate a set of partial tile prefixes to allow hoisting and sinking out of
the unrolled innermost loops produced by the optimization of the matrix
multiplication.
In case it cannot be proved that the number of loop iterations can be evenly
divided by tile sizes and we tile and unroll the point loop, the isl generates
conditional expressions. Subsequently, the conditional expressions can prevent
stores and loads of the unrolled loops from being sunk and hoisted.
The patch isolates a set of partial tile prefixes, which have exactly Mr x Nr
iterations of the two innermost loops, the result of the loop tiling performed
by the matrix multiplication optimization, where Mr and Mr are parameters of
the micro-kernel. This helps to get rid of the conditional expressions of
the unrolled innermost loops. Probably this approach can be replaced with
padding in future.
In case of, for example, the gemm from Polybench/C 3.2 and parametric loop
bounds, it helps to increase the performance from 7.98 GFlops (27.71% of
theoretical peak) to 21.47 GFlops (74.57% of theoretical peak). Hence, we
get the same performance as in case of scalar loops bounds.
It also cause compile time regression. The compile-time is increased from
0.795 seconds to 0.837 seconds in case of scalar loops bounds and from 1.222
seconds to 1.490 seconds in case of parametric loops bounds.
Reviewed-by: Michael Kruse <llvm@meinersbur.de>
Differential Revision: https://reviews.llvm.org/D29244
llvm-svn: 294564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
logging mode.
Summary:
Fixing a bug I found when testing a reader for the FDR format. Function ID is
now correctly packed into the 28 bits which are documented for it instead of being
masked to all ones.
Reviewers: dberris, pelikan, eugenis
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29698
llvm-svn: 294563
|
| |
|
|
|
|
| |
We only implemented it for one of the 3 HLE instructions and that instruction is also under the RTM flag. Clang only implements the RTM flag from its command line.
llvm-svn: 294562
|
| |
|
|
|
|
|
|
| |
any instructions and not tested.
If we implement intrinsics for their instructions in the future, the feature flags can be added back with proper testing.
llvm-svn: 294561
|
| |
|
|
| |
llvm-svn: 294560
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does the following.
1. Adds an Intrinsic int_x86_clzero which works with __builtin_ia32_clzero
2. Identifies clzero feature using cpuid info. (Function:8000_0008, Checks if EBX[0]=1)
3. Adds the clzero feature under znver1 architecture.
4. The custom inserter is added in Lowering.
5. A testcase is added to check the intrinsic.
6. The clzero instruction is added to assembler test.
Patch by Ganesh Gopalasubramanian with a couple formatting tweaks, a disassembler test, and using update_llc_test.py from me.
Differential revision: https://reviews.llvm.org/D29385
llvm-svn: 294558
|
| |
|
|
|
|
|
|
|
| |
cctools would pad the string table to a sizeof(int32_t) (explicitly
printed out by cctools rather than 4). This adjusts the string table to
make it more compatible with cctools, but is insufficient to make ld64
happy.
llvm-svn: 294557
|
| |
|
|
|
|
|
|
| |
This is causing build failure when building libc++abi with libunwind.
This reverts commit 42bf29501dfa79f211841de060386d539933e811.
llvm-svn: 294556
|
| |
|
|
|
|
| |
'const' on StringRef parameters adds no guarantees. Remove it.
llvm-svn: 294555
|
| |
|
|
|
|
|
|
|
| |
libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.
Differential Revision: https://reviews.llvm.org/D29573
llvm-svn: 294554
|
| |
|
|
|
|
|
|
|
|
|
| |
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29575
llvm-svn: 294553
|
| |
|
|
|
|
|
|
|
|
|
| |
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29574
llvm-svn: 294552
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Functions that have a dynamic alloca require a base register which is defined to
be X19 on AArch64 and r6 on ARM. We have defined the swifterror register to be
the same register. Use a different callee save register for swifterror instead:
X21 on AArch64
R8 on ARM
rdar://30433803
llvm-svn: 294551
|
| |
|
|
|
|
|
|
|
| |
It turns out that some of our negative tests were not in fact providing the
test coverage we expected: they were passing because the vtables were failing
an early check that they were constant. Fix this by changing the globals in
these tests to constants.
llvm-svn: 294550
|
| |
|
|
|
|
|
|
|
|
| |
CommandObjectVersion.cpp calls lldb_private::GetVersion (present in lldbBase).
This should fix the unittest link on windows. I am not sure why is this not
present on other platforms -- my guess is that there lldbBase is included in
the link through some other dependency chain.
llvm-svn: 294549
|
| |
|
|
|
|
|
|
| |
SubtargetFeature; other minor fixes (NFC).
Same changes in files affected by reduced SubtargetFeature.h dependencies.
llvm-svn: 294548
|
| |
|
|
| |
llvm-svn: 294534
|
| |
|
|
|
|
|
|
|
|
| |
Summary: Reflects the change in https://reviews.llvm.org/D29662
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29721
llvm-svn: 294533
|
| |
|
|
|
|
|
| |
Was reverted with r294447 due to undefined behavior with negative offsets
in DBG_VALUE instructions.
llvm-svn: 294532
|
| |
|
|
|
|
| |
There's no instruction to implement it.
llvm-svn: 294531
|
| |
|
|
|
|
|
|
| |
It'll usually be immediately legalized back to a libcall, but occasionally
something can be done with it so we'd just as well enable that flexibility from
the start.
llvm-svn: 294530
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29733
llvm-svn: 294529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'this returns'
We mark X0 as preserved by a call that passes the returned parameter.
x0 = ...
fun(x0) // no implicit def of x0
This no longer is valid if we pass the parameter in a different register then
the returned value as is the case with a swiftself parameter (passed in x20).
x20 = ...
fun(x20) // there should be an implict def of x8
rdar://30425845
llvm-svn: 294527
|
| |
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 294526
|
| |
|
|
|
|
| |
This is preparation to reduce MC headers dependencies.
llvm-svn: 294525
|
| |
|
|
| |
llvm-svn: 294524
|
| |
|
|
| |
llvm-svn: 294523
|
| |
|
|
|
|
|
|
| |
Summary: Documentation update for https://reviews.llvm.org/D29662
Differential Revision: https://reviews.llvm.org/D29722
llvm-svn: 294522
|
| |
|
|
|
|
|
|
|
|
| |
The Mips plugins conditionally link the Mips backend, so we need to conditionally add the target as a dependency.
This resolves a bot failure from r294515.
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/4606/steps/build%20android/logs/stdio
llvm-svn: 294521
|
| |
|
|
|
|
|
| |
Hopefully this'll be nuked by tablegen pretty soon, but until then it's
reasonably important for supporting C++ operator new[].
llvm-svn: 294520
|
| |
|
|
|
|
|
|
| |
AArch64 has specific instructions to multiply two numbers at double the width
and produce the high part of the result. These can be used to implement LLVM's
mul.with.overflow instructions fairly simply. Helps with C++ operator new[].
llvm-svn: 294519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement getRegPressureLimit and getRegPressureSetLimit callbacks in
SIRegisterInfo.
This makes standard converge scheduler to behave almost the same as
GCNScheduler, sometime slightly better sometimes a bit worse.
In gerenal that is also possible to switch GCNScheduler to use these
callbacks instead of getMaxWaves(), which also makes GCNScheduler
slightly better on some tests and slightly worse on another. A big
win is behavior with converge scheduler.
Note, these are used not only by scheduling, but in places like
MachineLICM.
Differential Revision: https://reviews.llvm.org/D29700
llvm-svn: 294518
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29662
llvm-svn: 294517
|
| |
|
|
| |
llvm-svn: 294516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool.
This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too.
Help testing would be greatly appreciated.
Reviewers: labath, zturner
Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits
Differential Revision: https://reviews.llvm.org/D29352
llvm-svn: 294515
|