| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
fix the test.
llvm-svn: 144146
|
| |
|
|
| |
llvm-svn: 144145
|
| |
|
|
|
|
| |
opaque values. Silly C type system.
llvm-svn: 144144
|
| |
|
|
|
|
| |
// rdar://10415026
llvm-svn: 144143
|
| |
|
|
| |
llvm-svn: 144142
|
| |
|
|
|
|
|
| |
Change the flow of the SATestAdd so that it could be used for regenerating
the reference output without exiting with an error.
llvm-svn: 144141
|
| |
|
|
|
|
|
|
| |
MCInsts.
Patch by Jack Carter.
llvm-svn: 144139
|
| |
|
|
|
|
| |
*headdesk*
llvm-svn: 144138
|
| |
|
|
|
|
| |
redundant 'strong'.
llvm-svn: 144136
|
| |
|
|
|
|
| |
There is no need to involve the LiveRegs array and kill() any longer.
llvm-svn: 144133
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 144132
|
| |
|
|
|
|
|
|
|
|
| |
This new function will decrement the reference count, and collapse a
domain value when the last reference is gone.
This simplifies DomainValue reference counting, and decouples it from
the LiveRegs array.
llvm-svn: 144131
|
| |
|
|
|
|
| |
and is different than the normal name.
llvm-svn: 144130
|
| |
|
|
|
|
|
|
|
|
| |
basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.
llvm-svn: 144124
|
| |
|
|
|
|
| |
ldm or ldr pairs.
llvm-svn: 144123
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 144122
|
| |
|
|
| |
llvm-svn: 144121
|
| |
|
|
| |
llvm-svn: 144120
|
| |
|
|
|
|
| |
type is strong by default too. // rdar://10410903
llvm-svn: 144118
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The old value may still be referenced by some live-out list, and we
don't wan't to collapse those instructions twice.
This fixes the "Can only swizzle VMOVD" assertion in some armv7 SPEC
builds.
<rdar://problem/10413292>
llvm-svn: 144117
|
| |
|
|
| |
llvm-svn: 144116
|
| |
|
|
| |
llvm-svn: 144115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analysis by Ted:
"
if (stateZero && !stateNotZero) {
is checking to see if:
(A) "it is possible for the value to be zero" (stateZero)
AND
(B) "it is not possible for the value to be non-zero" (!stateNotZero)
That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check. For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests. So the question is whether or not such an infeasible path might not get dropped earlier? I can't envision any right now.
Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:
C.addTransition(stateNotZero);
"
llvm-svn: 144114
|
| |
|
|
| |
llvm-svn: 144113
|
| |
|
|
| |
llvm-svn: 144112
|
| |
|
|
| |
llvm-svn: 144111
|
| |
|
|
|
|
|
|
|
| |
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.
llvm-svn: 144110
|
| |
|
|
| |
llvm-svn: 144108
|
| |
|
|
|
|
| |
yet so it will currently never get used in real tests
llvm-svn: 144107
|
| |
|
|
| |
llvm-svn: 144105
|
| |
|
|
| |
llvm-svn: 144104
|
| |
|
|
|
|
|
|
| |
Add support for trimming constants to GetDemandedBits. This fixes some funky
constant generation that occurs when stores are expanded for targets that don't
support unaligned stores natively.
llvm-svn: 144102
|
| |
|
|
|
|
| |
When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses
llvm-svn: 144100
|
| |
|
|
| |
llvm-svn: 144099
|
| |
|
|
| |
llvm-svn: 144095
|
| |
|
|
| |
llvm-svn: 144094
|
| |
|
|
|
|
|
|
|
|
|
|
| |
useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.
For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.
llvm-svn: 144089
|
| |
|
|
|
|
|
|
|
|
| |
Instead of using TempScop to find parameters, we detect them directly
on the SCEV. This allows us to remove the TempScop parameter detection
in a subsequent commit.
This fixes a bug reported by Marcello Maggioni <hayarms@gmail.com>
llvm-svn: 144087
|
| |
|
|
| |
llvm-svn: 144086
|
| |
|
|
|
|
|
|
|
| |
Previously we built a context that contained already all parameter dimensions
from the start. We now build a context without any parameter dimensions and
extend the context as needed. All parameter dimensions are added during final
realignment.
llvm-svn: 144085
|
| |
|
|
| |
llvm-svn: 144084
|
| |
|
|
| |
llvm-svn: 144083
|
| |
|
|
|
|
|
|
|
|
|
|
| |
implements unaligned loads and stores with assembler macro-instructions
ulw, usw, ulh, ulhu, ush, and this patch emits corresponding instructions
instead of these macros. Since each unaligned load/store is expanded
into two corresponding loads/stores where offset for second load/store is
modified by +3 (for words) or +1 (for halfwords).
Patch by Petar Jovanovic and Sasa Stankovic.
llvm-svn: 144081
|
| |
|
|
|
|
| |
optimize out "static" scope w/o "inline".
llvm-svn: 144080
|
| |
|
|
| |
llvm-svn: 144079
|
| |
|
|
|
|
|
|
| |
'(strong)'
property attribute.
llvm-svn: 144078
|
| |
|
|
| |
llvm-svn: 144077
|
| |
|
|
| |
llvm-svn: 144076
|
| |
|
|
|
|
|
|
|
|
|
| |
The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.
llvm-svn: 144075
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.
I want to have this feature available for the unwinder code. When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --
is the current pc value in an executable region (e.g. did they
jump to unallocated/unexecutable memory? we know how to unwind
from here if so.)
Is the stack pointer or the frame pointer the correct register
to use to find the caller's saved pc value?
Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.
llvm-svn: 144074
|