| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Implement the same interface as already available for dominators.
llvm-svn: 93194
|
| |
|
|
|
|
|
| |
latter may (eventually) perform multiple levels of desugaring (thus
breaking the newly-added tests) and the former is faster. Thanks, John!
llvm-svn: 93192
|
| |
|
|
|
|
| |
overlap, then select as an ADD instead.
llvm-svn: 93191
|
| |
|
|
| |
llvm-svn: 93190
|
| |
|
|
| |
llvm-svn: 93189
|
| |
|
|
|
|
|
|
|
| |
they redefine is a class-name but not a typedef-name, per C++0x
[dcl.typedef]p4. The code in the test was valid C++98 and is valid
C++0x, but an unintended consequence of DR56 made it ill-formed in
C++03 (which we were luck enough to implement). Fixes PR5455.
llvm-svn: 93188
|
| |
|
|
| |
llvm-svn: 93187
|
| |
|
|
|
|
| |
(fixes radar 6948022)
llvm-svn: 93186
|
| |
|
|
| |
llvm-svn: 93185
|
| |
|
|
|
|
|
|
| |
BRCOND was constant folded.
This fixes PR5980.
llvm-svn: 93184
|
| |
|
|
| |
llvm-svn: 93183
|
| |
|
|
| |
llvm-svn: 93182
|
| |
|
|
| |
llvm-svn: 93181
|
| |
|
|
|
|
|
|
| |
then a load if the
loads are not in the default address space because the transformation discards src value info.
llvm-svn: 93180
|
| |
|
|
|
|
| |
add a fixme.
llvm-svn: 93179
|
| |
|
|
|
|
|
| |
function, be sure to adjust the resulting argument type to a pointer
(if necessary). Fixes PR5910 and PR5949.
llvm-svn: 93178
|
| |
|
|
| |
llvm-svn: 93177
|
| |
|
|
| |
llvm-svn: 93175
|
| |
|
|
| |
llvm-svn: 93174
|
| |
|
|
|
|
| |
for all visible conversion functions.
llvm-svn: 93173
|
| |
|
|
| |
llvm-svn: 93172
|
| |
|
|
|
|
| |
are in characters.
llvm-svn: 93171
|
| |
|
|
|
|
|
|
| |
documentation.
Patch by Dustin Laurence!
llvm-svn: 93170
|
| |
|
|
| |
llvm-svn: 93169
|
| |
|
|
| |
llvm-svn: 93168
|
| |
|
|
|
|
| |
convention.
llvm-svn: 93167
|
| |
|
|
|
|
|
|
| |
templates. Previously, a little thinko in the code that replaced a
conversion function template with its redeclaration was causing some
very weird lookup behavior.
llvm-svn: 93166
|
| |
|
|
| |
llvm-svn: 93165
|
| |
|
|
|
|
|
| |
say either "array type" or "function type", whichever it is. No reason
to make the user guess.
llvm-svn: 93164
|
| |
|
|
|
|
| |
have a fix.
llvm-svn: 93163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
llvm-svn: 93162
|
| |
|
|
|
|
|
|
|
| |
- getToken is modeled after StringRef::split but it can split on multiple
separator chars and skips leading seperators.
- SplitString is a StringRef::split variant for more than 2 elements with the
same behaviour as getToken.
llvm-svn: 93161
|
| |
|
|
|
|
|
|
|
|
|
| |
has an immediate with at least 32 bits of leading zeros, to avoid needing to
materialize that immediate in a register first.
FileCheckize, tidy, and extend a testcase to cover this case.
This fixes rdar://7527390.
llvm-svn: 93160
|
| |
|
|
|
|
| |
in a function. Fixes radar 7522803.
llvm-svn: 93159
|
| |
|
|
|
|
|
|
| |
new AsmPrinter. This is perhaps less elegant than describing them
in terms of MOV32r0 and subreg operations, but it allows the
current register to rematerialize them.
llvm-svn: 93158
|
| |
|
|
| |
llvm-svn: 93157
|
| |
|
|
| |
llvm-svn: 93156
|
| |
|
|
|
|
| |
single user. The _su forms are intended for non-top-level nodes.
llvm-svn: 93155
|
| |
|
|
| |
llvm-svn: 93154
|
| |
|
|
|
|
|
|
|
|
| |
"ASTContext::getTypeSize() / 8". Replace [u]int64_t variables with CharUnits
ones as appropriate.
Also rename RawType, fromRaw(), and getRaw() in CharUnits to QuantityType,
fromQuantity(), and getQuantity() for clarity.
llvm-svn: 93153
|
| |
|
|
|
|
| |
allow the instruction to be 3address-fied if needed.
llvm-svn: 93152
|
| |
|
|
|
|
|
|
| |
ignore alignment requirements for SIMD memory operands. This
is useful on architectures like the AMD 10h that do not trap on
unaligned references if a status bit is twiddled at startup time.
llvm-svn: 93151
|
| |
|
|
|
|
| |
function. Fixes PR5985.
llvm-svn: 93150
|
| |
|
|
|
|
|
| |
Make InsertDbgValueIntrinsic() and get Offset take and recieve a uint64_t.
Get constness correct for getVariable() and getValue().
llvm-svn: 93149
|
| |
|
|
|
|
| |
The old test case has a little mistake.
llvm-svn: 93148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
good code on PR4216:
_test_bitfield: ## @test_bitfield
orl $32962, %edi
movl $4294941946, %eax
andq %rdi, %rax
ret
instead of:
_test_bitfield:
movl $4294941696, %ecx
movl %edi, %eax
orl $194, %edi
orl $32768, %eax
andq $250, %rdi
andq %rax, %rcx
movq %rdi, %rax
orq %rcx, %rax
ret
Evan is looking into the remaining andq+imm -> andl optimization.
llvm-svn: 93147
|
| |
|
|
|
|
| |
This with previous patch fixes a OSAtomic test case.
llvm-svn: 93146
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BitsToClear case. This allows it to promote expressions which have an
and/or/xor after the lshr, promoting cases like test2 (from PR4216)
and test3 (random extample extracted from a spec benchmark).
clang now compiles the code in PR4216 into:
_test_bitfield: ## @test_bitfield
movl %edi, %eax
orl $194, %eax
movl $4294902010, %ecx
andq %rax, %rcx
orl $32768, %edi
andq $39936, %rdi
movq %rdi, %rax
orq %rcx, %rax
ret
instead of:
_test_bitfield: ## @test_bitfield
movl %edi, %eax
orl $194, %eax
movl $4294902010, %ecx
andq %rax, %rcx
shrl $8, %edi
orl $128, %edi
shlq $8, %rdi
andq $39936, %rdi
movq %rdi, %rax
orq %rcx, %rax
ret
which is still not great, but is progress.
llvm-svn: 93145
|
| |
|
|
|
|
|
|
|
| |
new BitsToClear result which allows us to start promoting
expressions that end with a lshr-by-constant. This is
conservatively correct and better than what we had before
(see testcases) but still needs to be extended further.
llvm-svn: 93144
|
| |
|
|
| |
llvm-svn: 93143
|