| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
memcpy. (Spotted by looking at IR.)
llvm-svn: 132226
|
| |
|
|
|
|
|
|
|
| |
getMatchingSuperRegClass()
was saying that the matching superregister class of GR32_NOREX in GR64_NOREX_NOSP
is GR64_NOREX, which drops the NOSP constraint. This fixes PR10032.
llvm-svn: 132225
|
| |
|
|
|
|
|
|
|
|
| |
subregisters:
When a value is in a subregister, at least report the location as being
the superregister. We should extend the .td files to encode the bit
range so that we can produce a DW_OP_bit_piece.
llvm-svn: 132224
|
| |
|
|
|
|
| |
literals to 1. This can significantly impact the size of the string data, and as far as I know, the alignment doesn't help performance. rdar://9078969 .
llvm-svn: 132223
|
| |
|
|
| |
llvm-svn: 132222
|
| |
|
|
| |
llvm-svn: 132221
|
| |
|
|
|
|
| |
this. XFAIL'd, because the COFF AsmParser can't handle .section yet.
llvm-svn: 132220
|
| |
|
|
| |
llvm-svn: 132219
|
| |
|
|
|
|
|
|
| |
class type (or array thereof), eliminating some redundant checks
(thanks Eli!) and adding some tests where the behavior differs in
C++98/03 vs. C++0x.
llvm-svn: 132218
|
| |
|
|
|
|
| |
code in one place. Re-apply 131534 and fix the multi-step promotion of integers.
llvm-svn: 132217
|
| |
|
|
| |
llvm-svn: 132216
|
| |
|
|
|
|
|
|
| |
says, it's hard to pick good line numbers for this transformation, but something is better than nothing.
rdar://9143729
llvm-svn: 132215
|
| |
|
|
| |
llvm-svn: 132214
|
| |
|
|
| |
llvm-svn: 132213
|
| |
|
|
| |
llvm-svn: 132212
|
| |
|
|
|
|
| |
tools issues. rdar://9514789
llvm-svn: 132211
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to PR2536, the old spiller had trouble with the IMPLICIT_DEF in this
code:
%reg1028<def> = MOV16rm %reg0, 1, %reg0, <ga:g_5>, Mem:LD(2,2) [g_5 + 0]
%reg1039<def> = IMPLICIT_DEF
%reg1038<def> = INSERT_SUBREG %reg1039, %reg1028, 2
%reg1025<def> = AND32ri %reg1038, 65534, %%EFLAGS<imp-def>
However, today we emit a zero-extending load instead:
%vreg10<def> = MOVZX32rm16 %noreg, 1, %noreg, <ga:@g_5>, %noreg; %mem:LD2[@g_5] GR32:%vreg10
%vreg0<def> = AND32ri %vreg10, 65534, %%EFLAGS<imp-def,dead>; %GR32:%vreg0,%vreg10
This makes the test pointless since it no longer creates the spiller hazard.
llvm-svn: 132210
|
| |
|
|
|
|
|
|
| |
to be careful to emit landing pads that are always prepared to handle a
cleanup path. This is correct mostly because of the fix to the LLVM
inliner, r132200.
llvm-svn: 132209
|
| |
|
|
|
|
|
|
|
| |
nontemplate in Sema::InstantiateTemplateDecl.
This should make the issue in PR10026 more visible, although it's not
going to fix it because something is violating this precondition.
llvm-svn: 132208
|
| |
|
|
|
|
|
|
| |
fixes aliasing issues with the old and new names as well as adds test
cases for the auto-upgrader.
Fixes rdar 9472944.
llvm-svn: 132207
|
| |
|
|
|
|
| |
size, select appropraite form.
llvm-svn: 132206
|
| |
|
|
|
|
|
|
|
|
| |
suffix (e.g. .xdata$myfunc). The suffix part isn't implemented yet, but
I'll get to it in the next patch.
Fix up all callers of the affected functions. Make them pass said suffix to
the function.
llvm-svn: 132205
|
| |
|
|
|
|
| |
for pair's swap. I needed to create an __is_nothrow_swappable<T>::value trait that was smart enought to answer false when __is_swappable<T>::value is false. Otherwise one gets compile-time errors when using pair or tuple of non-swappable types, even if you never try to swap the pair or tuple.
llvm-svn: 132204
|
| |
|
|
| |
llvm-svn: 132203
|
| |
|
|
| |
llvm-svn: 132202
|
| |
|
|
|
|
|
|
| |
prevents LICM sinking from erasing debug intrinsics which don't dominate any exit block of the loop.
rdar://9143943 .
llvm-svn: 132201
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the selector for the landing pad must provide all available information
about the handlers, filters, and cleanups within that landing pad
- calls to _Unwind_Resume must be converted to branches to the enclosing
lpad so as to avoid re-entering the unwinder when the lpad claimed it
was going to handle the exception in some way
This is quite specific to libUnwind-based unwinding. In an effort to not
interfere too badly with other unwinders, and with existing hacks in frontends,
this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does
nothing with selectors if it cannot find a selector call for either lpad.
llvm-svn: 132200
|
| |
|
|
|
|
|
| |
The register allocators know to filter reserved registers from the allocation
orders, so we don't need all of this boilerplate.
llvm-svn: 132199
|
| |
|
|
|
|
| |
This fixes regressions reported by buildbots as a fallout of r132193.
llvm-svn: 132197
|
| |
|
|
| |
llvm-svn: 132196
|
| |
|
|
| |
llvm-svn: 132195
|
| |
|
|
| |
llvm-svn: 132194
|
| |
|
|
| |
llvm-svn: 132193
|
| |
|
|
|
|
| |
These should be DW_OP_bit_piece of CR (64).
llvm-svn: 132192
|
| |
|
|
|
|
|
|
| |
so that it looks at the initializer of a local variable of class type
(or array thereof) to determine whether it's just an implicit
invocation of the trivial default constructor. Fixes PR10034.
llvm-svn: 132191
|
| |
|
|
| |
llvm-svn: 132190
|
| |
|
|
|
|
|
|
|
|
| |
- Flip order of bitfields. This gets our output matching GAS.
- Handle case where the end of the prolog wasn't specified.
- If the resulting unwind info struct is less than 8 bytes, pad to 8 bytes.
Add a test for the latter two.
llvm-svn: 132188
|
| |
|
|
|
|
|
|
| |
refer to them.
I tested this with both check-all and the gdb testsuite.
llvm-svn: 132187
|
| |
|
|
|
|
| |
noexcept workarounds.
llvm-svn: 132186
|
| |
|
|
|
|
|
|
| |
trying instsimplify on the arm where we know the compared value.
Stuff like "x == y ? y : x&y" now folds into "x&y".
llvm-svn: 132185
|
| |
|
|
| |
llvm-svn: 132181
|
| |
|
|
| |
llvm-svn: 132180
|
| |
|
|
|
|
| |
followed by a conditional and imm8.
llvm-svn: 132179
|
| |
|
|
| |
llvm-svn: 132178
|
| |
|
|
|
|
|
| |
Use them to calculate the offset inside the prolog. Emit this value when
emitting the unwind codes.
llvm-svn: 132177
|
| |
|
|
|
|
|
|
| |
to 4 bytes.
I'm surprised no one caught the missing break statements.
llvm-svn: 132176
|
| |
|
|
| |
llvm-svn: 132175
|
| |
|
|
|
|
|
|
| |
still report leaks, but they're spurious now. Valgrind cannot peer into
std::vector objects--or any dynamic array, for that matter--because it doesn't
know how big the array is.
llvm-svn: 132174
|
| |
|
|
|
|
|
| |
already defined, and err when the PushMachFrame operation isn't the first
operation (if specified at all).
llvm-svn: 132173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
|