| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
forcing 16-byte alignment. This fixes misaligned SmallVector accesses via ExtractValueInst's SmallVector data member.
llvm-svn: 162331
|
| |
|
|
|
|
| |
Patch by Weiming Zhao <weimingz@codeaurora.org>.
llvm-svn: 162329
|
| |
|
|
|
|
| |
strict weak ordering, and don't pass possibly-null pointers to dyn_cast.
llvm-svn: 162314
|
| |
|
|
|
|
|
|
|
|
| |
int64_t, Symbol64TableEntry is actually only stored with 4-byte alignment
within the file.
The usage of #pragma pack here is copied from the corresponding code in
Support/Endian.h, so shouldn't introduce any new portability problems.
llvm-svn: 162312
|
| |
|
|
|
|
|
| |
no cost to using memcpy here: the fixed code is optimized by LLVM to perfect
machine code.
llvm-svn: 162311
|
| |
|
|
| |
llvm-svn: 162310
|
| |
|
|
|
|
| |
WeakVH::operator*).
llvm-svn: 162309
|
| |
|
|
| |
llvm-svn: 162306
|
| |
|
|
|
|
|
|
|
|
| |
According to http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
it's suggested that compile_commands.json in the root of the LLVM source tree
should be a symlink to the json file produced by your build system of choice.
So here's a patch so it doesn't turn up in git status, etc.
llvm-svn: 162305
|
| |
|
|
|
|
|
|
| |
any way.
Thanks to Duncan Sands for catching this random file in code review.
llvm-svn: 162304
|
| |
|
|
|
|
|
|
|
|
| |
Even looking at the revision history I couldn't quite piece together why this
cast was ever written in the first place, but I assume it was because of some
change in the inheritance, perhaps this function was reimplemented in a
derived type & this caller was meant to get the base version (& it wasn't
virtual)?
llvm-svn: 162301
|
| |
|
|
| |
llvm-svn: 162300
|
| |
|
|
|
|
| |
on a patch by Andy/PaX. I added the support for dot and dollar.
llvm-svn: 162298
|
| |
|
|
|
|
|
|
|
| |
this is the index of the operand that failed to match.
Note: This may cause a buildbot failure due to an API mismatch in clang. Should
recover with my next commit to clang.
llvm-svn: 162295
|
| |
|
|
| |
llvm-svn: 162292
|
| |
|
|
|
|
|
| |
consistent with the other "expected identifier" errors.
Extracted from the Andy/PaX patch. I added the test.
llvm-svn: 162291
|
| |
|
|
|
|
| |
suggested by David Blaikie.
llvm-svn: 162286
|
| |
|
|
|
|
| |
PR9673
llvm-svn: 162284
|
| |
|
|
| |
llvm-svn: 162283
|
| |
|
|
| |
llvm-svn: 162282
|
| |
|
|
| |
llvm-svn: 162281
|
| |
|
|
|
|
|
|
|
| |
The MCJIT doesn't need or want a TargetJITInfo. That's vestigal from the old
JIT, so just remove it.
rdar://12119347
llvm-svn: 162280
|
| |
|
|
|
|
|
|
|
| |
number of bits was bigger than 32. I checked every use of this function
that I could find and it looks like the maximum number of bits is 32, so I've
added an assertion checking this property, and a type cast to (hopefully) stop
PVS-Studio from warning about this in the future.
llvm-svn: 162277
|
| |
|
|
| |
llvm-svn: 162276
|
| |
|
|
|
|
|
|
|
|
| |
This optimization is really just replacing allocas wholesale with
globals, there is no scalarization.
The underlying motivation for this patch is to simplify the SROA pass
and focus it on splitting and promoting allocas.
llvm-svn: 162271
|
| |
|
|
| |
llvm-svn: 162270
|
| |
|
|
|
|
| |
sub-pass is off by default for now. Patch by Reid Watson. Note: this patch changes the interface between LLVM and compiler-rt parts of asan. The corresponding patch to compiler-rt will follow.
llvm-svn: 162268
|
| |
|
|
| |
llvm-svn: 162267
|
| |
|
|
| |
llvm-svn: 162264
|
| |
|
|
| |
llvm-svn: 162263
|
| |
|
|
|
|
| |
switch. Condense code a bit. No functional change.
llvm-svn: 162261
|
| |
|
|
|
|
| |
forms.
llvm-svn: 162260
|
| |
|
|
|
|
| |
null_frag.
llvm-svn: 162257
|
| |
|
|
| |
llvm-svn: 162256
|
| |
|
|
|
|
|
|
|
|
| |
*** Bad machine code: Explicit definition marked as use ***
- function: test_cos
- basic block: BB#0 L.entry (0x7ff2a2024fd0)
- instruction: VSETLNi32 %D11, %D11<undef>, %R0, 0, pred:14, pred:%noreg, %Q5<imp-use,kill>, %Q5<imp-def>
- operand 0: %D11
llvm-svn: 162247
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
This patch was originally committed as r161460, but reverted again
because of assertion failures. Now that duplicate Machine CFG edges have
been eliminated, this works properly.
llvm-svn: 162233
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
IR that hasn't been through SimplifyCFG can look like this:
br i1 %b, label %r, label %r
Make sure we don't create duplicate Machine CFG edges in this case.
Fix the machine code verifier to accept conditional branches with a
single CFG edge.
llvm-svn: 162230
|
| |
|
|
|
|
|
|
|
|
|
|
| |
LLVM IR has labeled duplicate CFG edges, but since Machine CFG edges
don't have labels, it doesn't make sense to allow duplicates. There is
no way of telling what the edges mean.
Duplicate CFG edges cause confusion when dealing with edge weights. It
seems that code producing duplicate CFG edges usually does the wrong
thing with edge weights.
llvm-svn: 162227
|
| |
|
|
|
|
|
| |
This pass often has weird CFG hacks and hand-written MI building code
that can go wrong in many ways.
llvm-svn: 162224
|
| |
|
|
|
|
|
| |
Verify that the predecessor and successor lists are consistent and free
of duplicates.
llvm-svn: 162223
|
| |
|
|
|
|
|
| |
The test case ARM/2011-05-04-MultipleLandingPadSuccs.ll was creating
duplicate successor list entries.
llvm-svn: 162222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows us to use cmake to specify a cross compiler: target different
than host. In particular, it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time.
Here is the command line that I have used to test my patches to create a Hexagon
cross compiler hosted on x86:
$ cmake -G Ninja -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu ..
$ ninja check
llvm-svn: 162219
|
| |
|
|
|
|
| |
The patch adds a missing case for the Hexagon target in cmake/config-ix.cmake.
llvm-svn: 162218
|
| |
|
|
| |
llvm-svn: 162217
|
| |
|
|
| |
llvm-svn: 162214
|
| |
|
|
|
|
| |
Patch by Petar Jovanovic.
llvm-svn: 162213
|
| |
|
|
| |
llvm-svn: 162201
|
| |
|
|
| |
llvm-svn: 162196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner tries to optimise a BUILD_VECTOR by checking if it
consists purely of get_vector_elts from one or two source vectors. If
so, it either makes a concat_vectors node or a shufflevector node.
However, it doesn't check the element type width of the underlying
vector, so if you have this sequence:
Node0: v4i16 = ...
Node1: i32 = extract_vector_elt Node0
Node2: i32 = extract_vector_elt Node0
Node3: v16i8 = BUILD_VECTOR Node1, Node2, ...
It will attempt to:
Node0: v4i16 = ...
NewNode1: v16i8 = concat_vectors Node0, ...
Where this is actually invalid because the element width is completely
different. This causes an assertion failure on DAG legalization stage.
Fix:
If output item type of BUILD_VECTOR differs from input item type.
Make concat_vectors based on input element type and then bitcast it to the output vector type. So the case described above will transformed to:
Node0: v4i16 = ...
NewNode1: v8i16 = concat_vectors Node0, ...
NewNode2: v16i8 = bitcast NewNode1
llvm-svn: 162195
|
| |
|
|
| |
llvm-svn: 162194
|