Previously, even when a pre-increment load or store was generated,
we often needed to keep a copy of the original base register for use
with other offsets. If all of these offsets are constants (including
the offset which was combined into the addressing mode), then this is
clearly unnecessary. This change adjusts these other offsets to use the
new incremented address.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174746 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to the cost-model change in r174713 which splits
the cost of a memory operation between the address computation and the
actual memory access. In r174713, this cost is always added to the
memory operation cost, and so BBVectorize will do the same.
Currently, this new cost function is used only by ARM, and I don't
have any ARM test cases for BBVectorize. Assistance in generating some
good ARM test cases for BBVectorize would be greatly appreciated!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174743 91177308-0d34-0410-b5e6-96231b3b80d8
Aside from the question of whether we report a warning or an error when we
can't satisfy a requested stack object alignment, the current implementation
of this is not good. We're not providing any source location in the diagnostics
and the current warning is not connected to any warning group so you can't
control it. We could improve the source location somewhat, but we can do a
much better job if this check is implemented in the front-end, so let's do that
instead. <rdar://problem/13127907>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174741 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to help from Nadav and Hal, I have a more reasonable (and even
correct!) approach. This specifically penalizes the insertelement
and extractelement operations for the performance hit that will occur
on PowerPC processors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174725 91177308-0d34-0410-b5e6-96231b3b80d8
isn't using the default calling convention. However, if the transformation is
from a call to inline IR, then the calling convention doesn't matter.
rdar://13157990
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174724 91177308-0d34-0410-b5e6-96231b3b80d8
of lines which weren't being explicitly looked at and were printing incorrect results. These
values clearly must lie within 32 bits, so the casts are definitely safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174717 91177308-0d34-0410-b5e6-96231b3b80d8
Adds a function to target transform info to query for the cost of address
computation. The cost model analysis pass now also queries this interface.
The code in LoopVectorize adds the cost of address computation as part of the
memory instruction cost calculation. Only there, we know whether the instruction
will be scalarized or not.
Increase the penality for inserting in to D registers on swift. This becomes
necessary because we now always assume that address computation has a cost and
three is a closer value to the architecture.
radar://13097204
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174713 91177308-0d34-0410-b5e6-96231b3b80d8
Attribute references are of this form:
define void @foo() #0#1#2 { ... }
Parse them for function attributes. If there's more than one reference, then
they are merged together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174697 91177308-0d34-0410-b5e6-96231b3b80d8
allowed size for the instruction. This code uses RegScavenger to fix this.
We sometimes need 2 registers for Mips16 so we must handle things
differently than how register scavenger is normally used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174696 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 3854a5d90fee52af1065edbed34521fff6cdc18d.
This causes a clang unit test to hang: vtable-available-externally.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174692 91177308-0d34-0410-b5e6-96231b3b80d8
The functionality of ParseOptionalFuncAttrs was there in
ParseFnAttributeValuePairs. So just use that instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174686 91177308-0d34-0410-b5e6-96231b3b80d8
syms before constructing the compile units so we're not emitting
section references to sections not there already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174663 91177308-0d34-0410-b5e6-96231b3b80d8
Add #include <unistd.h> to OProfileWrapper.cpp. This provides the declarations for 'read' and 'close' that are otherwise missing, and result in 'error: <foo> was not declared in this scope'.
This matches the issue as reported in bug 15055 "Can no longer compile LLVM with --with-oprofile"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174661 91177308-0d34-0410-b5e6-96231b3b80d8
Certain vector operations don't vectorize well with the current
PowerPC implementation. Element insert/extract performs poorly
without VSX support because Altivec requires going through memory.
SREM, UREM, and VSELECT all produce bad scalar code.
There's a lot of work to do for the cost model before
autovectorization will be tuned well, and this is not an attempt to
address the larger problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174660 91177308-0d34-0410-b5e6-96231b3b80d8
Remove all the unused code.
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174656 91177308-0d34-0410-b5e6-96231b3b80d8
Allows nexuiz to run with radeonsi.
Patch by: Michel Dänzer
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174655 91177308-0d34-0410-b5e6-96231b3b80d8
20 more little piglits with radeonsi.
Patch by: Michel Dänzer
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174654 91177308-0d34-0410-b5e6-96231b3b80d8
The _SGPR variants where wrong.
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174653 91177308-0d34-0410-b5e6-96231b3b80d8
v2: rebased on current upstream
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174652 91177308-0d34-0410-b5e6-96231b3b80d8
This is for the case when no processor is passed to the backend. This
prevents the
'' is not a recognized processor for this target (ignoring processor)
warning from being generated by clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174651 91177308-0d34-0410-b5e6-96231b3b80d8
We don't want too many classes in a pass and the classes obscure the details. I
was going a little overboard with object modeling here. Replace classes by
generic code that handles both loads and stores.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174646 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: Michel Dänzer
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174634 91177308-0d34-0410-b5e6-96231b3b80d8
Handle vectors of 1 to 16 integers.
Change the intrinsic names to prevent the wrong one from being selected at
runtime due to the overloading.
Patch By: Michel Dänzer
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174633 91177308-0d34-0410-b5e6-96231b3b80d8
v1i32, v2i32, v8i32 and v16i32.
Only add VGPR register classes for integer vector types, to avoid attempts
copying from VGPR to SGPR registers, which is not possible.
Patch By: Michel Dänzer
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174632 91177308-0d34-0410-b5e6-96231b3b80d8
Use sub0-15 everywhere.
Patch by: Michel Dänzerr
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174610 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions compare two floating point values and return an
integer true (-1) or false (0) value.
When compiling code generated by the Mesa GLSL frontend, the SET*_DX10
instructions save us four instructions for most branch decisions that
use floating-point comparisons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174609 91177308-0d34-0410-b5e6-96231b3b80d8
A double inclusion will pretty much always be an error in TableGen, so
there's no point going on just to die with "def already defined" or
whatnot.
I'm not too thrilled about the "public: ... private: ..." to expose the
DependenciesMapTy, but I really didn't see a better way to keep that
type centralized. It's a smell that indicates that some refactoring is
needed to make this code more loosely coupled.
This should avoid all bugs of the same nature as PR15189.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174582 91177308-0d34-0410-b5e6-96231b3b80d8
1. Moved a comment from ObjCARCOpts.cpp -> ObjCARCContract.cpp.
2. Removed a comment from ObjCARCOpts.cpp that was already moved to
ObjCARCAliasAnalysis.h/.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174581 91177308-0d34-0410-b5e6-96231b3b80d8
