| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
edge is critical, then split it so we can insert the store.
rdar://13126179
llvm-svn: 174418
|
|
|
|
| |
llvm-svn: 174412
|
|
|
|
|
|
| |
This was fixed by r174402.
llvm-svn: 174405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when a fragment is relaxed, its size is modified, but its
offset is not (it gets laid out as a side effect of checking whether
it needs relaxation), then all subsequent fragments are invalidated
because their offsets need to change. When bundling is enabled,
relaxed fragments need to get laid out again, because the increase in
size may push it over a bundle boundary. So instead of only
invalidating subsequent fragments, also invalidate the fragment that
gets relaxed, which causes it to get laid out again.
This patch also fixes some trailing whitespace and fixes the
bundling-related debug output of MCFragments.
llvm-svn: 174401
|
|
|
|
| |
llvm-svn: 174393
|
|
|
|
|
|
|
|
| |
Emitting the function name allows us to check for it in the FileCheck
tests so we can make sure FileCheck is checking the output of the
correct function.
llvm-svn: 174392
|
|
|
|
|
|
| |
for the existing instructions.
llvm-svn: 174389
|
|
|
|
| |
llvm-svn: 174380
|
|
|
|
|
|
| |
requires +Asserts.
llvm-svn: 174379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the loop vectorizer cost model, we used to ignore stores/loads of a pointer
type when computing the widest type within a loop. This meant that if we had
only stores/loads of pointers in a loop we would return a widest type of 8bits
(instead of 32 or 64 bit) and therefore a vector factor that was too big.
Now, if we see a consecutive store/load of pointers we use the size of a pointer
(from data layout).
This problem occured in SingleSource/Benchmarks/Shootout-C++/hash.cpp (reduced
test case is the first test in vector_ptr_load_store.ll).
radar://13139343
llvm-svn: 174377
|
|
|
|
|
|
|
|
| |
alignment for a load,"
It caused hangups in compiling clang/lib/Parse/ParseDecl.cpp and clang/lib/Driver/Tools.cpp in stage2 on some hosts.
llvm-svn: 174374
|
|
|
|
|
|
|
|
| |
The sh_link in the ELF section header of .ARM.exidx should
be filled with the section index of the corresponding text
section.
llvm-svn: 174372
|
|
|
|
|
|
| |
Also adds some costs for vector integer float conversions.
llvm-svn: 174371
|
|
|
|
|
|
|
|
| |
MicroMips architectures.
Contributer: Zoran Jovanovic
llvm-svn: 174360
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and enables the instruction printer to print aliased
instructions.
Due to usage of RegisterOperands a change in common
code (utils/TableGen/AsmWriterEmitter.cpp) is required
to get the correct register value if it is a RegisterOperand.
Contributer: Vladimir Medic
llvm-svn: 174358
|
|
|
|
|
|
| |
skeleton CU as part of the DWARF5 split dwarf proposal.
llvm-svn: 174351
|
|
|
|
|
|
| |
DWARF5 split dwarf proposal.
llvm-svn: 174350
|
|
|
|
|
|
|
|
|
| |
externally_initialized return false for hasDefiniteInitializer and
hasUniqueInitializer.
rdar://12580965.
llvm-svn: 174345
|
|
|
|
|
|
|
|
|
|
|
| |
it would replace the load with one with the higher alignment. However, it did
not place the new load in the worklist, which prevented later DAG combines in
the same phase (for example, target-specific combines) from ever seeing it.
This patch corrects that oversight, and updates some tests whose output changed
due to slightly different DAGCombine outputs.
llvm-svn: 174343
|
|
|
|
|
|
| |
externally_initialized.
llvm-svn: 174340
|
|
|
|
|
|
|
|
|
|
|
| |
Per discussion in rdar://13127907, we should emit a hard error only if
people write code where the requested alignment is larger than achievable
and assumes the low bits are zeros. A warning should be good enough when
we are not sure if the source code assumes the low bits are zeros.
rdar://13127907
llvm-svn: 174336
|
|
|
|
| |
llvm-svn: 174331
|
|
|
|
|
|
|
| |
I didn't see those because the test case used "not grep". FileCheck the test and
XFAIL it, preserving the old optimization, so this can be fixed eventually.
llvm-svn: 174330
|
|
|
|
|
|
|
|
| |
lowering.
Fixes PR15141.
llvm-svn: 174327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required disabling a PowerPC optimization that did the following:
input:
x = BUILD_VECTOR <i32 16, i32 16, i32 16, i32 16>
lowered to:
tmp = BUILD_VECTOR <i32 8, i32 8, i32 8, i32 8>
x = ADD tmp, tmp
The add now gets folded immediately and we're back at the BUILD_VECTOR we
started from. I don't see a way to fix this currently so I left it disabled
for now.
Fix some trivially foldable X86 tests too.
llvm-svn: 174325
|
|
|
|
| |
llvm-svn: 174321
|
|
|
|
|
|
| |
variable lists)
llvm-svn: 174305
|
|
|
|
|
|
|
|
|
|
|
| |
Swift has a renaming dependency if we load into D subregisters. We don't have a
way of distinguishing between insertelement operations of values from loads and
other values. Therefore, we are pessimistic for now (The performance problem
showed up in example 14 of gcc-loops).
radar://13096933
llvm-svn: 174300
|
|
|
|
|
|
|
|
|
|
| |
The main lists of debug info metadata attached to the compile_unit had an extra
layer of metadata nodes they went through for no apparent reason. This patch
removes that (& still passes just as much of the GDB 7.5 test suite). If anyone
can show evidence as to why these extra metadata nodes are there I'm open to
reverting this patch & documenting why they're there.
llvm-svn: 174266
|
|
|
|
|
|
| |
This checkin makes hello world work.
llvm-svn: 174264
|
|
|
|
| |
llvm-svn: 174259
|
|
|
|
|
|
|
| |
Fix a bug in DAGCombine. The symptom is mistakenly optimizing expression
"x + x*x" into "x * 3.0".
llvm-svn: 174239
|
|
|
|
|
|
|
|
| |
Testing case is reduced from MultiSource/BenchMarks/Prolangs-C++/deriv1.
rdar://problem/13071590
llvm-svn: 174235
|
|
|
|
| |
llvm-svn: 174230
|
|
|
|
| |
llvm-svn: 174210
|
|
|
|
|
|
|
|
|
| |
1) allows the use of RIP-relative addressing in 32-bit LEA instructions under
x86-64 (ILP32 and LP64)
2) separates the size of address registers in 64-bit LEA instructions from
control by ILP32/LP64.
llvm-svn: 174208
|
|
|
|
| |
llvm-svn: 174196
|
|
|
|
|
|
|
|
|
|
| |
pointers too.
Prepare it for vectors of pointers and handle simple cases. We don't handle
complicated cases because accumulateConstantOffset bails on pointer vectors.
Fixes selfhost on i386.
llvm-svn: 174179
|
|
|
|
|
|
|
|
| |
Only Linux is supported at the moment, and other platforms quickly fault. As a
result these tests would fail on non-Linux hosts. It may be worth making the
tests more generic again as more platforms are supported.
llvm-svn: 174170
|
|
|
|
|
|
| |
transformation is illegal.
llvm-svn: 174156
|
|
|
|
| |
llvm-svn: 174152
|
|
|
|
|
|
|
|
|
|
|
|
| |
remaining use of AliasAnalysis concepts such as isIdentifiedObject to
prove pointer inequality.
@external_compare in test/Transforms/InstSimplify/compare.ll shows a simple
case where a noalias argument can be equal to a global variable address, and
while AliasAnalysis can get away with saying that these pointers don't alias,
instsimplify cannot say that they are not equal.
llvm-svn: 174122
|
|
|
|
|
|
|
| |
be equal, since there's nothing preventing a caller from correctly predicting
the stack location of an alloca.
llvm-svn: 174119
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AttrBuilder is for building a collection of attributes. The Attribute object
holds only one attribute. So it's not really useful for the Attribute object to
have a creator which takes an AttrBuilder.
This has two fallouts:
1. The AttrBuilder no longer holds its internal attributes in a bit-mask form.
2. The attributes are now ordered alphabetically (hence why the tests have changed).
llvm-svn: 174110
|
|
|
|
|
|
|
| |
Patch by: Vincent Lejeune
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 174099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-worked version of r174048.
Given source IR:
call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !14), !dbg !15
we used to generate
call void @llvm.dbg.declare(metadata !27, metadata !28), !dbg !29
!27 = metadata !{null}
With this patch, we will correctly generate
call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !27), !dbg !28
Looking up %argc.addr in ValueMap will return null, since %argc.addr is already
correctly set up, we can use identity mapping.
rdar://problem/13089880
llvm-svn: 174093
|
|
|
|
|
|
| |
past the natural stack alignment.
llvm-svn: 174085
|
|
|
|
|
|
| |
boundaries
llvm-svn: 174067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174054
|
|
|
|
|
|
| |
breakage with builds without X86-support.
llvm-svn: 174052
|