| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
trampoline forms. Both of these were correct in LLVM 3.0, and we don't
need to support LLVM 2.9 and earlier in mainline.
llvm-svn: 145174
|
| |
|
|
| |
llvm-svn: 145173
|
| |
|
|
|
|
| |
only produced by LLVM 2.9 and earlier. LLVM 3.0 and later prefers "load volatile".
llvm-svn: 145172
|
| |
|
|
|
|
| |
instead of 'volatile load', which is archaic.
llvm-svn: 145171
|
| |
|
|
| |
llvm-svn: 145170
|
| |
|
|
|
|
|
| |
I think this is the last of autoupgrade that can be removed in 3.1.
Can the atomic upgrade stuff also go?
llvm-svn: 145169
|
| |
|
|
| |
llvm-svn: 145168
|
| |
|
|
| |
llvm-svn: 145167
|
| |
|
|
|
|
| |
LLVM 3.0 and later.
llvm-svn: 145165
|
| |
|
|
|
|
| |
back to 3.0
llvm-svn: 145164
|
| |
|
|
| |
llvm-svn: 145163
|
| |
|
|
|
|
|
|
|
| |
Besides cleaning up the repetition in the installhdrs target, the point of this
change is to provide a separate do-installhdrs target that can be used directly
from clang's runtime/libcxx makefile to install a copy of the headers along
with clang. <rdar://problem/10397739>
llvm-svn: 145162
|
| |
|
|
|
|
| |
These instructions are not generated by the backend yet, this will come in a later commit.
llvm-svn: 145161
|
| |
|
|
|
|
|
| |
Removing that buildbot would be a better solution, but this is at least
a temporary workaround.
llvm-svn: 145160
|
| |
|
|
|
|
| |
Fix a couple of 80-column violations.
llvm-svn: 145159
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass. This is designed to achieve one of the important optimizations
that the old code placement pass did, but more simply.
This is a somewhat rough and *very* conservative version of the
transform. We could get a lot fancier here if there are profitable cases
to do so. In particular, this only looks for a single pattern, it
insists that the loop backedge being rotated away is the last backedge
in the chain, and it doesn't provide any means of doing better in-loop
placement due to the rotation. However, it appears that it will handle
the important loops I am finding in the LLVM test suite.
llvm-svn: 145158
|
| |
|
|
| |
llvm-svn: 145157
|
| |
|
|
| |
llvm-svn: 145154
|
| |
|
|
|
|
| |
Simplify some shuffle lowering code since V1 can never be UNDEF due to canonalizing that occurs when shuffle nodes are created.
llvm-svn: 145153
|
| |
|
|
| |
llvm-svn: 145152
|
| |
|
|
|
|
|
| |
and on clang, which seams to handled "=b" correctly even when ebx is the
PIC register.
llvm-svn: 145149
|
| |
|
|
|
|
| |
not be type specific. Now we just have integer high and low and floating point high and low. Pattern matching will choose the correct instruction based on the vector type.
llvm-svn: 145148
|
| |
|
|
| |
llvm-svn: 145147
|
| |
|
|
|
|
| |
class template member.
llvm-svn: 145146
|
| |
|
|
|
|
| |
bullet for AVX.
llvm-svn: 145145
|
| |
|
|
| |
llvm-svn: 145144
|
| |
|
|
|
|
| |
for adding other tests.
llvm-svn: 145143
|
| |
|
|
|
|
| |
and linux.
llvm-svn: 145142
|
| |
|
|
|
|
|
|
| |
was returning incorrect values in rare cases, and incorrectly marking
exact conversions as inexact in some more common cases. Fixes PR11406, and a
missed optimization in test/CodeGen/X86/fp-stack-O0.ll.
llvm-svn: 145141
|
| |
|
|
| |
llvm-svn: 145138
|
| |
|
|
|
|
|
| |
I don't see how the project is using LLVM and we really can't list every user of
the clang analyzer. Sorry.
llvm-svn: 145137
|
| |
|
|
| |
llvm-svn: 145136
|
| |
|
|
| |
llvm-svn: 145135
|
| |
|
|
| |
llvm-svn: 145134
|
| |
|
|
|
|
|
|
|
| |
tablegen patterns for scalar FMA4 operations and intrinsic. Also
add tests for vfmaddsd.
Patch by Jan Sjodin
llvm-svn: 145133
|
| |
|
|
| |
llvm-svn: 145129
|
| |
|
|
|
|
|
|
|
|
| |
templates" works inside a friend function definition at class scope.
Basically we have to look into the parent *lexical* DeclContext for friend functions at class scope. That's because calling GetParent() return the namespace or file DeclContext.
This fixes all remaining cases of "Unqualified lookup into dependent bases of class templates" when parsing MFC code with clang.
llvm-svn: 145127
|
| |
|
|
|
|
| |
128-bit versions and let the operand type disinquish. Also fix the load form of the v8i32 patterns for these to realize that the load would be promoted to v4i64.
llvm-svn: 145126
|
| |
|
|
|
|
| |
the 128-bit versions and let the vector type distinguish.
llvm-svn: 145125
|
| |
|
|
|
|
|
|
| |
a lot.
While at it pull the trivial ctor in line.
llvm-svn: 145124
|
| |
|
|
| |
llvm-svn: 145122
|
| |
|
|
| |
llvm-svn: 145121
|
| |
|
|
|
|
|
|
|
|
|
|
| |
need lots of fanciness around retaining a reference to a Chain's slot in
the BlockToChain map, but that's all gone now. We can just go directly
to allocating the new chain (which will update the mapping for us) and
using it.
Somewhat gross mechanically generated test case replicates the issue
Duncan spotted when actually testing this out.
llvm-svn: 145120
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
conflicts, we should only be adding the first block of the chain to the
list, lest we try to merge into the middle of that chain. Most of the
places we were doing this we already happened to be looking at the first
block, but there is no reason to assume that, and in some cases it was
clearly wrong.
I've added a couple of tests here. One already worked, but I like having
an explicit test for it. The other is reduced from a test case Duncan
reduced for me and used to crash. Now it is handled correctly.
llvm-svn: 145119
|
| |
|
|
| |
llvm-svn: 145118
|
| |
|
|
| |
llvm-svn: 145117
|
| |
|
|
| |
llvm-svn: 145116
|
| |
|
|
|
|
|
|
|
|
| |
pointer mismatch. Cases covered are: initialization, assignment, and function
arguments. Additional text will give the extra information about the nature
of the mismatch: different classes for member functions, wrong number of
parameters, different parameter type, different return type, and function
qualifier mismatch.
llvm-svn: 145114
|
| |
|
|
|
|
|
|
| |
- lower unaligned loads/stores.
- encode the size operand of instructions INS and EXT.
- emit relocation information needed for JAL (jump-and-link).
llvm-svn: 145113
|
| |
|
|
| |
llvm-svn: 145112
|