| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.
llvm-svn: 146994
|
| |
|
|
| |
llvm-svn: 146993
|
| |
|
|
|
|
|
|
| |
enabled
only when the target ABI is N64.
llvm-svn: 146992
|
| |
|
|
| |
llvm-svn: 146990
|
| |
|
|
| |
llvm-svn: 146989
|
| |
|
|
| |
llvm-svn: 146988
|
| |
|
|
| |
llvm-svn: 146987
|
| |
|
|
| |
llvm-svn: 146986
|
| |
|
|
| |
llvm-svn: 146985
|
| |
|
|
|
|
| |
Patch by Andrew Wilkins!
llvm-svn: 146984
|
| |
|
|
| |
llvm-svn: 146983
|
| |
|
|
|
|
| |
Patch by Dimitry Andric!
llvm-svn: 146982
|
| |
|
|
| |
llvm-svn: 146981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
llvm-svn: 146980
|
| |
|
|
| |
llvm-svn: 146978
|
| |
|
|
|
|
|
| |
(Both used for Linux gnueabi)
No behavioral change yet (no tests need so far)
llvm-svn: 146977
|
| |
|
|
|
|
| |
the definition of that class. Fixes PR11613 / <rdar://problem/10604077>.
llvm-svn: 146976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure that I see in the current version is:
LLVM ERROR: Cannot select: 0x18b8f70: v4i64 = X86ISD::VZEXT_MOVL 0x18beee0 [ID=14]
0x18beee0: v4i64 = insert_subvector 0x18b8c70, 0x18b9170, 0x18b9570 [ID=13]
0x18b8c70: v4i64 = insert_subvector 0x18b9870, 0x18bf4e0, 0x18b9970 [ID=12]
0x18b9870: v4i64 = undef [ID=4]
0x18bf4e0: v2i64 = bitcast 0x18bf3e0 [ID=10]
0x18bf3e0: v4i32 = BUILD_VECTOR 0x18b9770, 0x18b9770, 0x18b9770, 0x18b9770 [ID=8]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9770: i32 = TargetConstant<0> [ID=6]
0x18b9970: i32 = Constant<0> [ID=3]
0x18b9170: v2i64 = undef [ORD=1] [ID=1]
0x18b9570: i32 = Constant<2> [ID=5]
llvm-svn: 146975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use the zero-undefined variants of CTTZ and CTLZ. These are just simple
patterns for now, there is more to be done to make real world code using
these constructs be optimized and codegen'ed properly on X86.
The existing tests are spiffed up to check that we no longer generate
unnecessary cmov instructions, and that we generate the very important
'xor' to transform bsr which counts the index of the most significant
one bit to the number of leading (most significant) zero bits. Also they
now check that when the variant with defined zero result is used, the
cmov is still produced.
llvm-svn: 146974
|
| |
|
|
|
|
|
| |
Pulling the template implementation into the header to guarantee
that it's visible to all possible instantiations.
llvm-svn: 146973
|
| |
|
|
|
|
|
|
|
|
| |
In case we can not analyze an access function, we do not discard the SCoP, but
assume conservatively that all memory accesses that can be derived from our base
pointer may be accessed.
Patch provided by: Marcello Maggioni <hayarms@gmail.com>
llvm-svn: 146972
|
| |
|
|
|
|
|
| |
This is the first step towards migrating more of the parser
implementation into the parser class.
llvm-svn: 146971
|
| |
|
|
| |
llvm-svn: 146970
|
| |
|
|
|
|
| |
unneeded builtins for SSE pcmp. Change SSE pcmpeqq and pcmpgtq to not use builtins and just use vector == and >.
llvm-svn: 146969
|
| |
|
|
| |
llvm-svn: 146968
|
| |
|
|
| |
llvm-svn: 146967
|
| |
|
|
|
|
| |
likely to stay either way that discussion ends up resolving itself.
llvm-svn: 146966
|
| |
|
|
|
|
| |
suppress/fix these problems properly when we figure out how to keep LLVM -Wweak-vtables clean)
llvm-svn: 146965
|
| |
|
|
|
|
|
|
| |
1. pointer-vector
2. type legalizer changes and vector-select
3. X86 ISA changes.
llvm-svn: 146964
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Not long ago, I tightened up the type checking for pointer arguments of
Neon intrinsics to match the specifications provided by ARM. One consequence
was that it became impossible to access the unaligned versions of a few
Neon load/store operations. Since there are just a few of these intrinsics
where it makes a difference, I think it's better to relax the type checking
than to either introduce new non-standard unaligned intrinsics or to disallow
intrinsics for the unaligned operations.
llvm-svn: 146963
|
| |
|
|
|
|
| |
error detection.
llvm-svn: 146962
|
| |
|
|
| |
llvm-svn: 146961
|
| |
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
| |
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
|
| |
|
|
|
|
| |
and mergeDuplicates()
llvm-svn: 146958
|
| |
|
|
| |
llvm-svn: 146957
|
| |
|
|
| |
llvm-svn: 146956
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
llvm-svn: 146955
|
| |
|
|
|
|
|
|
|
| |
rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check
Add a NULL check for SBValue.CreateValueFromExpression().
llvm-svn: 146954
|
| |
|
|
|
|
| |
for-range-declaration. PR11601.
llvm-svn: 146953
|
| |
|
|
|
|
| |
Windows subversion clients isn't setup to default to eol:native again...
llvm-svn: 146952
|
| |
|
|
| |
llvm-svn: 146951
|
| |
|
|
|
|
| |
Fixes PR11571: Instruction does not dominate all uses
llvm-svn: 146950
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers. But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore. Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early. This also more accurately reflects
when the registers are clobbered.
llvm-svn: 146949
|
| |
|
|
|
|
|
|
|
| |
rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check
Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.
llvm-svn: 146948
|
| |
|
|
| |
llvm-svn: 146940
|
| |
|
|
| |
llvm-svn: 146939
|
| |
|
|
| |
llvm-svn: 146938
|
| |
|
|
|
|
|
|
|
|
| |
"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.
rdar://10604663
llvm-svn: 146937
|
| |
|
|
| |
llvm-svn: 146936
|