| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
This is for AMDGPU to implement v2i64 extract as extract of
half of a v4i32.
This is covered by existing tests and used by a future
commit which makes 64-bit vectors legal types on AMDGPU.
llvm-svn: 252630
|
| |
|
|
|
|
|
|
|
|
| |
This is a cleaned up version of a patch by John Regehr with permission. Originally found via the souper tool.
If we add an odd number to x, then bitwise-and the result with x, we know that the low bit of the result must be zero. Either it was zero in x originally, or the add cleared it in the temporary value. As a result, one of the two values anded together must have the bit cleared.
Differential Revision: http://reviews.llvm.org/D14315
llvm-svn: 252629
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When configuring various llvm projects that use AddLLVM.cmake, this warning is
emitted many times, flooding the screen:
Policy CMP0007 is not set: list command no longer ignores empty elements.
The fix is removing an extra semicolon.
Differential Revision: http://reviews.llvm.org/D14339
llvm-svn: 252628
|
| |
|
|
| |
llvm-svn: 252627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure WeakAny variables are imported as ExternalWeak declarations. To
handle WeakAny more consistently and fix this issue:
1) Update helper doImportAsDefinition to properly flag WeakAny variables
and aliases as not importing defintions.
Update callers of doImportAsDefinition to remove now redundant checks for
WeakAny aliases, or ignore aliases, as appropriate.
2) Add any !doImportAsDefinition GVs to DoNotLinkFromSource set during
linking of the GV prototype, where we usually add GVs to the
DoNotLinkFromSource set for other reasons.
Remove now unnecessary adding of WeakAny aliases to
DoNotLinkFromSource set from copyGlobalAliasProto.
Remove now unnecessary guard against linking non-imported function
bodies from ModuleLinker::run.
llvm-svn: 252626
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isCheapToSpeculateCtlz()
AArch64 has instructions for efficient count-leading/trailing-zeros, so this should be
considered a cheap operation (and therefore fair game for speculation) for any AArch64
implementation.
The net result of allowing this speculation for the regression tests in this
patch is that we get this code:
ctlz:
clz w0, w0
ret
cttz:
rbit w8, w0
clz w0, w8
ret
Instead of:
ctlz:
cbz w0, .LBB0_2
clz w0, w0
ret
.LBB0_2:
orr w0, wzr, #0x20
ret
cttz:
cbz w0, .LBB1_2
rbit w8, w0
clz w0, w8
ret
.LBB1_2:
orr w0, wzr, #0x20
ret
See D14469 for the larger motivation.
Differential Revision: http://reviews.llvm.org/D14505
llvm-svn: 252625
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13819
llvm-svn: 252624
|
| |
|
|
|
|
|
| |
This reverts commit r252604, as it broke all ARM and AArch64 buildbots, as
well as some x86, et al.
llvm-svn: 252623
|
| |
|
|
|
|
|
|
|
|
| |
CompilerDecl class to do the job in an abstract way.
Fixed a crash that would happen if you tried to get the name of a constructor or destructor by calling "getDeclName()" instead of calling getName() (which would assert and crash).
Added the ability to get function arguments names from SBFunction.
llvm-svn: 252622
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14495
llvm-svn: 252621
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since 252422 we do not only distinguish two ScopArrayInfo kinds, PHI nodes
and others, but work with three kind of ScopArrayInfo objects. SCALAR, PHI and
ARRAY objects. Instead of keeping two boolean flags isPHI and isScalar and
wonder what an ScopArrayInfo object of kind (!isScalar && isPHI) is, we
list now explicitly the three different possible types of memory objects.
This change also allows us to remove the confusing nested pairs that have
been used in ArrayInfoMapTy.
llvm-svn: 252620
|
| |
|
|
|
|
|
|
| |
prevents passing empty -isysroot arguments
This is a minor cleanup to the macho_embedded builtins.
llvm-svn: 252619
|
| |
|
|
|
|
|
| |
* Setting CMAKE_*_FLAGS_${BUILD_TYPE} isn't really needed since we're setting the same value everywhere
* functions sanitize variables differently from macros, darwin_add_embedded_builtin_libraries should be a macro otherwise it won't alter the variables.
llvm-svn: 252618
|
| |
|
|
| |
llvm-svn: 252617
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one of the problems noted in PR25016:
https://llvm.org/bugs/show_bug.cgi?id=25016
and:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/090998.html
The spilling problem is independent and not addressed by this patch.
The MachineCombiner was doing reassociations that don't improve or even worsen the critical path.
This is caused by inclusion of the "slack" factor when calculating the critical path of the original
code sequence. If we don't add that, then we have a more conservative cost comparison of the old code
sequence vs. a new sequence. The more liberal calculation must be preserved, however, for the AArch64
MULADD patterns because benchmark regressions were observed without that.
The two failing test cases now have identical asm that does what we want:
a + b + c + d ---> (a + b) + (c + d)
Differential Revision: http://reviews.llvm.org/D13417
llvm-svn: 252616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we also model scalar reads it can happen that a pointer appears in both
a scalar read access as well as the base pointer of an array access. As this
is a little surprising, we add a specific test case to document this behaviour.
To my understanding it should be OK to have a read from an array A[] and
read/write accesses to A[...]. isl is treating these arrays as unrelated as
their dimensionality differs. This seems to be correct as A[] remains constant
throughout the execution of the scop and is not affected by the reads/writes to
A[...]. If this causes confusion, it might make sense to make this behaviour
more obvious by using different names (e.g., A_scalar[], A[...]).
llvm-svn: 252615
|
| |
|
|
| |
llvm-svn: 252614
|
| |
|
|
| |
llvm-svn: 252613
|
| |
|
|
|
|
| |
uncovered a couple bugs in the _v type traits. Fixed those, too
llvm-svn: 252612
|
| |
|
|
|
|
|
| |
Commit r252422 introduced an unnecessary complicated test case. Reduce it to
the part that actually triggered the original issue.
llvm-svn: 252611
|
| |
|
|
|
|
| |
the bug report.
llvm-svn: 252610
|
| |
|
|
|
|
| |
No test case, as this code path is currently only used for debugging.
llvm-svn: 252609
|
| |
|
|
|
|
| |
Fixes http://llvm.org/PR25208.
llvm-svn: 252608
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In polly the first dimensions of an array as well as all scalars do not carry
any size information. This commit makes this explicit in the interface of
getDimensionSize. Before this commit getDimensionSize(0) returned the size of
the first dimension that carried a size. After this commit getDimensionSize(i)
will either return the size of dimension 'i' or assert in case 'i' does not
carry a size or does not exist at all.
This very same behaviour was already present in getDimensionSizePw(). This
commit also adds assertions that ensure getDimensionSizePw() is called
appropriately.
llvm-svn: 252607
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added fixes for stage2 failures: CMOV is not commutable; commuting the operands results in the condition being flipped! d'oh!
Original commit message:
If we have a CMOV, OR and AND combination such as:
if (x & CN)
y |= CM;
And:
* CN is a single bit;
* All bits covered by CM are known zero in y;
Then we can convert this to a sequence of BFI instructions. This will always be a win if CM is a single bit, will always be no worse than the TST & OR sequence if CM is two bits, and for thumb will be no worse if CM is three bits (due to the extra IT instruction).
llvm-svn: 252606
|
| |
|
|
| |
llvm-svn: 252605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is fix for PR24059.
When we are hoisting instruction above some condition it may turn out
that metadata on this instruction was control dependant on the condition.
This metadata becomes invalid and we need to drop it.
This patch should cover most obvious places of speculative execution (which
I have found by greping isSafeToSpeculativelyExecute). I think there are more
cases but at least this change covers the severe ones.
Differential Revision: http://reviews.llvm.org/D14398
llvm-svn: 252604
|
| |
|
|
|
|
|
| |
This is needed for targets which do not support big-endian with the default
triple.
llvm-svn: 252603
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Memory references are now printed as follows:
Old New
Scalars: i64 MemRef_val[*] i64 MemRef_val;
Arrays: i64 MemRef_A[*][%m][%o][8] i64 MemRef_A[*][%m][%o];
We do not print any more information about the element size in the type. Such
information has already been available in a comment after the scalar/array
declaration. It was redundant and did not match well with what people were used
from C.
llvm-svn: 252602
|
| |
|
|
|
|
| |
for those.
llvm-svn: 252601
|
| |
|
|
|
|
|
|
| |
The local variable Hi is never being read.
Issue identified by the Clang static analyzer.
llvm-svn: 252600
|
| |
|
|
| |
llvm-svn: 252599
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.
This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.
Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For big-endian targets, when we merge two halfword loads into a word load, the
order of the halfwords in the loaded value is reversed compared to
little-endian, so the load-store optimiser needs to swap the destination
registers.
This does not affect merging of two word loads, as we use ldp, which treats the
memory as two separate 32-bit words.
llvm-svn: 252597
|
| |
|
|
| |
llvm-svn: 252596
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14499
llvm-svn: 252595
|
| |
|
|
| |
llvm-svn: 252593
|
| |
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14492
llvm-svn: 252592
|
| |
|
|
|
|
|
|
| |
Add support for the new dyld shared cache format on
ios etc devices.
Small changes for classifying ObjC metadata symbols.
llvm-svn: 252588
|
| |
|
|
| |
llvm-svn: 252587
|
| |
|
|
|
|
| |
Prevents duplicate names appearing from multiple macro expansions. NFC
llvm-svn: 252586
|
| |
|
|
| |
llvm-svn: 252585
|
| |
|
|
|
|
|
|
|
|
| |
"Modify internal breakpoints so they resolve just like external
breakpoints do. This allow you to set symbol and file + line internal
breakpoints and have them get updated correctly."
<rdar://problem/16931767>
llvm-svn: 252584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triple for a process. He writes, "Changes to the way setting the
triple works on a target so that if the target has passed a fully
specified triple, and the newly passed triple is not a revamp of
the current one, and the current one is fully specified, then do
not replace the existing triple."
Triple handling got a bit more complicated on mac with the addition
of ios/watchos/tvos and their simulators, and tracking the correct
os versions for them so expressions are compiled with the expected
APIs available to the user.
<rdar://problem/19820698>
llvm-svn: 252583
|
| |
|
|
| |
llvm-svn: 252582
|
| |
|
|
|
|
|
|
|
|
| |
Also, add an async error message if the dyld solib loaded callback function
can't find an ABI (which results in no solibs being loaded in the process).
This is a big error and we should call attention to it.
<rdar://problem/23471384>
llvm-svn: 252581
|
| |
|
|
| |
llvm-svn: 252580
|
| |
|
|
| |
llvm-svn: 252579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For CoreCLR on Windows, stack probes must be emitted as inline sequences that probe successive stack pages
between the current stack limit and the desired new stack pointer location. This implements support for
the inline expansion on x64.
For in-body alloca probes, expansion is done during instruction lowering. For prolog probes, a stub call
is initially emitted during prolog creation, and expanded after epilog generation, to avoid complications
that arise when introducing new machine basic blocks during prolog and epilog creation.
Added a new test case, modified an existing one to exclude non-x64 coreclr (for now).
Add test case
Fix tests
llvm-svn: 252578
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: brad.king, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14523
llvm-svn: 252576
|