| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 174817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original syntax for the attribute groups was ambiguous. For example:
declare void @foo() #1
#0 = attributes { noinline }
The '#0' would be parsed as an attribute reference for '@foo' and not as a
top-level entity. In order to continue forward while waiting for a decision on
what the correct syntax is, I'm changing it to this instead:
declare void @foo() #1
attributes #0 = { noinline }
Repeat: This is TEMPORARY until we decide what the correct syntax should be.
llvm-svn: 174813
|
|
|
|
|
|
| |
We are going to place the AttributeSet into a DenseMap during assembly writing.
llvm-svn: 174812
|
|
|
|
|
|
| |
report_fatal_error)
llvm-svn: 174808
|
|
|
|
| |
llvm-svn: 174807
|
|
|
|
| |
llvm-svn: 174806
|
|
|
|
| |
llvm-svn: 174804
|
|
|
|
|
|
| |
not enabled yet).
llvm-svn: 174803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitcode writer would generate abbrev records saying that the abbrev should be
filled with fixed zero-bit bitfields (this happens in the .bc writer when
the number of types used in a module is exactly one, since log2(1) == 0).
In this case, just handle it as a literal zero. We can't "just fix" the writer
without breaking compatibility with existing bc files, so have the abbrev reader
do the substitution.
Strengthen the assert in read to reject reads of zero bits so we catch such
crimes in the future, and remove the special case designed to handle this.
llvm-svn: 174801
|
|
|
|
|
|
|
|
|
|
|
| |
instead of always 32-bits at a time) with two changes:
1. Make Read(0) always return zero without affecting the state of our cursor.
2. Hack word_t to always be 32 bits, as staging.
These two caveats will change shortly.
llvm-svn: 174800
|
|
|
|
| |
llvm-svn: 174791
|
|
|
|
| |
llvm-svn: 174790
|
|
|
|
|
|
|
|
|
| |
Handle chains in which the same offset is used for both loads and
stores to the same array.
Fixes rdar://11410078.
llvm-svn: 174789
|
|
|
|
| |
llvm-svn: 174786
|
|
|
|
|
|
| |
line table entries in assembly.
llvm-svn: 174785
|
|
|
|
|
|
| |
This is part of the plan to delete LiveVariables.
llvm-svn: 174783
|
|
|
|
|
|
| |
Enables raw_ostream I/O for BasicBlockPass.
llvm-svn: 174776
|
|
|
|
|
|
|
|
| |
This uses a liveness algorithm that does not depend on data from the
LiveVariables analysis, it is the first step towards removing
LiveVariables completely.
llvm-svn: 174774
|
|
|
|
|
|
|
|
|
|
|
| |
check_cxx_symbol_exists requires CMake 2.8.6, so even though I
recommended it to Owen it's probably better to stay away for now.
This check is not technically correct because we're checking <math.h>
but then using <cmath> in the actual code, but if we run into problems we
can do the same sort of dance as isinf() and isnan() where we check /both/
headers and then write a wrapper header around them.
llvm-svn: 174773
|
|
|
|
|
|
|
|
|
| |
to use -Wfoo instead of -Wno-foo. This works around a bug in some versions of
gcc, where it will silently accept an unknown -Wno-foo option, but will
generate an error for a compile which uses -Wno-foo if that compile also
triggers any warnings.
llvm-svn: 174770
|
|
|
|
| |
llvm-svn: 174764
|
|
|
|
|
|
|
| |
Also output a more useful error message.
NOTE: This is a candidate for the Mesa stable branch
llvm-svn: 174763
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a couple of bugs and incorrect assumptions,
in total four more piglit tests now pass.
v2: fix small bug in the dominator updating
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 174762
|
|
|
|
|
|
|
|
|
|
| |
Patch by: Christian König
Intersecting loop handling was wrong.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 174761
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we sometimes produce invalid code.
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 174760
|
|
|
|
| |
llvm-svn: 174756
|
|
|
|
| |
llvm-svn: 174749
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/12867368>"
This reverts r171041. This was a nice idea that didn't work out well.
Clang warnings need to be associated with warning groups so that they can
be selectively disabled, promoted to errors, etc. This simplistic patch didn't
allow for that. Enhancing it to provide some way for the backend to specify
a front-end warning type seems like overkill for the few uses of this, at
least for now.
llvm-svn: 174748
|
|
|
|
|
|
|
|
|
|
| |
same so we put in the comment field an indicator when we think we are
emitting the 16 bit version. For the direct object emitter, the difference is
important as well as for other passes which need an accurate count of
program size. There will be other similar putbacks to this for various
instructions.
llvm-svn: 174747
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174746
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 174743
|
|
|
|
| |
llvm-svn: 174742
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 174741
|
|
|
|
|
|
|
|
|
|
| |
This updates the current references to links that work for me.
In the future, we should update the list of references itself to provide
information on newer architecture variants.
Thanks to Sean Silva for pointing out that the current links were broken!
llvm-svn: 174739
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174725
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 174724
|
|
|
|
| |
llvm-svn: 174723
|
|
|
|
|
|
|
|
|
| |
but missed a couple
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.
llvm-svn: 174717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 174713
|
|
|
|
|
|
| |
and provide build instructions
llvm-svn: 174711
|
|
|
|
| |
llvm-svn: 174709
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174697
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174696
|
|
|
|
|
|
|
|
|
|
| |
included."
This reverts commit 3854a5d90fee52af1065edbed34521fff6cdc18d.
This causes a clang unit test to hang: vtable-available-externally.cpp.
llvm-svn: 174692
|
|
|
|
| |
llvm-svn: 174687
|
|
|
|
|
|
|
| |
The functionality of ParseOptionalFuncAttrs was there in
ParseFnAttributeValuePairs. So just use that instead.
llvm-svn: 174686
|
|
|
|
| |
llvm-svn: 174682
|
|
|
|
|
|
| |
over dynamic symbols.
llvm-svn: 174681
|
|
|
|
| |
llvm-svn: 174675
|
|
|
|
| |
llvm-svn: 174671
|