| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This reverts commit 317342 while investigating bot breakage.
llvm-svn: 317345
|
| |
|
|
| |
llvm-svn: 317342
|
| |
|
|
| |
llvm-svn: 317341
|
| |
|
|
|
|
|
|
| |
This preserves the debug info for the cast operation in the original location.
rdar://problem/33460652
llvm-svn: 317340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current LICM allows sinking an instruction only when it is exposed to exit
blocks through a trivially replacable PHI of which all incoming values are the
same instruction. This change enhance LICM to sink a sinkable instruction
through non-trivially replacable PHIs by spliting predecessors of loop
exits.
Reviewers: hfinkel, majnemer, davidxl, bmakam, mcrosier, danielcdh, efriedma, jtony
Reviewed By: efriedma
Subscribers: nemanjai, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D37163
llvm-svn: 317335
|
| |
|
|
| |
llvm-svn: 317334
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change the ISel matching of 'ins', 'dins[mu]' from tablegen code to
C++ code. This resolves an issue where ISel would select 'dins' instead
of 'dinsm' when the instructions size and position were individually in
range but their sum was out of range according to the ISA specification.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D39117
llvm-svn: 317331
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39546
llvm-svn: 317330
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Refactored the code to separate out common functions that are being
reused.
This is to reduce the changes for changes coming up wrt loop
predication with reverse loops.
This refactoring is what we have in our downstream code.
llvm-svn: 317324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also added a reserve() method to MapVector since we want to use that from
ADCE.
DenseMap does not provide deterministic iteration order so with that
we will handle the members of BlockInfo in random order, eventually
leading to random order of the blocks in the predecessor lists.
Without this change, I get the same predecessor order in about 90% of the
time when I compile a certain reproducer and in 10% I get a different one.
No idea how to make a proper test case for this.
Reviewers: kuhar, david2050
Reviewed By: kuhar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39593
llvm-svn: 317323
|
| |
|
|
|
|
| |
Fix undefined references: ExpandMemCmp belongs to CodeGen/, not Scalar/.
llvm-svn: 317318
|
| |
|
|
|
|
|
|
| |
Similar to the existing code to lower to PACKSS, we can use PACKUS if the input vector's leading zero bits extend all the way to the packed/truncated value.
We have to account for pre-SSE41 targets not supporting PACKUSDW
llvm-svn: 317315
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
InlineFunction can fail, for example when trying to inline vararg
fuctions. In those cases, we do not want to bump partial inlining
counters or set AnyInlined to true, because this could leave an unused
function hanging around.
Reviewers: davidxl, davide, gyiu
Reviewed By: davide
Subscribers: llvm-commits, eraman
Differential Revision: https://reviews.llvm.org/D39581
llvm-svn: 317314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GlobalISel TableGen backend didn't check for predicates on the
source children. This caused it to generate code for ARM patterns such
as SMLABB or similar, but without properly checking for the sext_16_node
part of the operands. This in turn meant that we would select SMLABB
instead of MLA for simple sequences such as s32 + s32 * s32, which is
wrong (we want a MLA on the full operands, not just their bottom 16
bits).
This patch forces TableGen to skip patterns with predicates on the src
children, so it doesn't generate code for SMLABB and other similar ARM
instructions at all anymore. AArch64 and X86 are not affected.
Differential Revision: https://reviews.llvm.org/D39554
llvm-svn: 317313
|
| |
|
|
|
|
|
|
|
| |
We're currently bailing out for Thumb targets while lowering formal
parameters, but there used to be some other checks before it, which
could've caused some functions (e.g. those without formal parameters) to
sneak through unnoticed.
llvm-svn: 317312
|
| |
|
|
|
|
|
|
|
|
| |
This patch combines the code that matches and merges TBAA access
tags. The aim is to simplify future changes and making sure that
these operations produce consistent results.
Differential Revision: https://reviews.llvm.org/D39463
llvm-svn: 317311
|
| |
|
|
|
|
|
|
|
| |
Make doSpillCalleeSavedRegs a member function, instead of passing most of the
members of PEI as arguments.
Differential Review: https://reviews.llvm.org/D35642
llvm-svn: 317309
|
| |
|
|
|
|
|
|
|
|
| |
Ideally we should probably produce WinEH here as well, but until
then, we can use dwarf exceptions, without any further changes
required in clang, libunwind or libcxxabi.
Differential Revision: https://reviews.llvm.org/D39535
llvm-svn: 317304
|
| |
|
|
| |
llvm-svn: 317303
|
| |
|
|
|
|
|
|
|
|
|
| |
GNU binutils nm doesn't error out on this, and some projects' build
systems can end up doing that in some cases. Allowing that seems like
a better target than trying to avoid user projects passing multiple
-g parameters to $NM.
Differential Revision: https://reviews.llvm.org/D39539
llvm-svn: 317301
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The character gets uppercased into 'I' when it's a global symbol.
In GNU binutils, nm prints 'I' for symbols classified by
bfd_is_ind_section - which probably isn't exactly/only import
tables.
When building for win32, (some incarnations of?) libtool has got
rules that try to inspect linked libraries, and in order to
be sure that it is linking to a DLL import library as opposed to
a static library, it expects to find the string " I " in the output
of $NM when run on such an import library.
GNU binutils nm also flags all of the .idata$X chunks as 'i' (while
this patch only makes it set on .idata$2 and .idata$6) and also
flags __imp__function as 'I'.
Differential Revision: https://reviews.llvm.org/D39540
llvm-svn: 317300
|
| |
|
|
|
|
| |
to isel patterns instead. Prefer 128-bit VALIGND/VALIGNQ over PALIGNR during lowering when possible.
llvm-svn: 317299
|
| |
|
|
| |
llvm-svn: 317298
|
| |
|
|
| |
llvm-svn: 317295
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39065
llvm-svn: 317292
|
| |
|
|
|
|
|
|
|
|
| |
A member of config was removed in this patch which resulted in errors I
didn't expect. Removing config.host_arch will take more work some I'm
readding that field.
Differential Revision: https://reviews.llvm.org/D39465
llvm-svn: 317289
|
| |
|
|
|
|
|
| |
This cl::opt has been dead for a while. It's no longer possible to run
the verifier without also verifying debug info.
llvm-svn: 317288
|
| |
|
|
|
|
|
|
|
|
| |
This fixes http://llvm.org/PR32560. We were missing a description for
half floating point type and as a result were using the FPR 32 mapping.
Because of the size mismatch the generic code was complaining that the
default mapping is not appropriate. Fix the mapping description so that
the default mapping can be properly applied.
llvm-svn: 317287
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 317286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mir-canon (MIRCanonicalizerPass) is a pass designed to reorder instructions and
rename operands so that two similar programs will diff more cleanly after being
run through mir-canon than they would otherwise. This project is still a work
in progress and there are ideas still being discussed for improving diff
quality.
M include/llvm/InitializePasses.h
M lib/CodeGen/CMakeLists.txt
M lib/CodeGen/CodeGen.cpp
A lib/CodeGen/MIRCanonicalizerPass.cpp
llvm-svn: 317285
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just aligning segment offsets to segment alignment is incorrect and also
wastes more space than is needed. The requirement is that p_offset ==
p_addr modulo p_align *not* that p_offset == 0 modulo p_align. Generally
speaking we've been using p_addr == 0 modulo p_align. In fact yaml2obj
can't even produce a valid situation which causes llvm-objcopy to
produce incorrect results because alignment and offset were both
inherited from the sections the program header covers. This change fixes
this bad behavior in llvm-objcopy.
Differential Revision: https://reviews.llvm.org/D39132
llvm-svn: 317284
|
| |
|
|
|
|
| |
I thought we had gotten all these priority bugs worked out, but I guess not.
llvm-svn: 317283
|
| |
|
|
|
|
|
|
|
|
| |
This fixes PR35015.
https://bugs.llvm.org/show_bug.cgi?id=35015
Differential Revision: https://reviews.llvm.org/D39345
llvm-svn: 317282
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have a test that I'd like to add to llvm that demands using more than
32-bits worth of address space. This test can't be run on 32-bit systems
because they don't have enough address space. The host triple should be
used to determine this instead of config.host_arch because on Debian
systems config.host_arch is not correct. This change adds the
"host-arch-is-64bit" feature to allow tests to restrict themselves to
the 64-bit case.
Differential Revision: https://reviews.llvm.org/D39465
llvm-svn: 317281
|
| |
|
|
| |
llvm-svn: 317280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently the block frequency analysis is an approximation for irreducible
loops.
The new irreducible loop metadata is used to annotate the irreducible loop
headers with their header weights based on the PGO profile (currently this is
approximated to be evenly weighted) and to help improve the accuracy of the
block frequency analysis for irreducible loops.
This patch is a basic support for this.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: mehdi_amini, llvm-commits, eraman
Differential Revision: https://reviews.llvm.org/D39028
llvm-svn: 317278
|
| |
|
|
|
|
|
| |
If the offset is an immediate, avoid putting it in a register
to get Rs+Rt<<#0.
llvm-svn: 317275
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The LLVM tools can be used as a replacement for binutils, in which case
it's convenient to create symlinks with the binutils names. Add support
for these symlinks in the build system. As with any other llvm tool
symlinks, the user can limit the installed symlinks by only adding the
desired ones to `LLVM_TOOLCHAIN_TOOLS`.
Differential Revision: https://reviews.llvm.org/D39530
llvm-svn: 317272
|
| |
|
|
|
|
|
|
| |
Patch by Harlan Haskins!
Differential Revision: https://reviews.llvm.org/D39568
llvm-svn: 317271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch allows us to predicate range checks that have a type narrower than
the latch check type. We leverage SCEV analysis to identify a truncate for the
latchLimit and latchStart.
There is also safety checks in place which requires the start and limit to be
known at compile time. We require this to make sure that the SCEV truncate expr
for the IV corresponding to the latch does not cause us to lose information
about the IV range.
Added tests show the loop predication over range checks that are of various
types and are narrower than the latch type.
This enhancement has been in our downstream tree for a while.
Reviewers: apilipenko, sanjoy, mkazantsev
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39500
llvm-svn: 317269
|
| |
|
|
| |
llvm-svn: 317267
|
| |
|
|
| |
llvm-svn: 317266
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM now requires a minimum of cmake 3.4.3, and all the policies
currently being set are present in that cmake version, so the
conditionals will always be true and are therefore unnecessary. The
movation is that the conditionals can give the false impression that the
policy settings are optional, whereas for example it's necessary to set
CMP0056 in order for `check_linker_flags` to operate correctly after
r316972. Inline the project version and language setting in the process.
Differential Revision: https://reviews.llvm.org/D39442
llvm-svn: 317264
|
| |
|
|
|
|
|
| |
After r316999, tools/dsymutil/X86/alias.test started failing in builds
that have threading disabled.
llvm-svn: 317263
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similarly to SVN r317189 for llvm-dlltool, these are probably
easier to find in a tools subdirectory with a name identical to
the tool, than in a toplevel directory with a different name.
This matches the move of LibDriver itself in SVN r302995.
Differential Revision: https://reviews.llvm.org/D39531
llvm-svn: 317262
|
| |
|
|
|
|
|
|
| |
flags. Don't use 'x86-64' ever.
'x86-64' has started to reflect a sort of generic tuning flag for more modern 64-bit CPUs. We probably shouldn't be using it as the name of an unidentifiable pentium4. So use nocona for all 64-bit pentium4s instead.
llvm-svn: 317230
|
| |
|
|
|
|
|
|
| |
CPUs in family 6 that has 64-bit support but not any newer SSE features. Use 'core2' instead
We know that's the earliest CPU with 64-bit support. x86-64 has taken on a role of representing a more modern 64-bit CPU so we probably shouldn't be using that when we can't identify things.
llvm-svn: 317229
|
| |
|
|
|
|
|
|
|
|
| |
- Improve wording
- Rename llvm-dsymutil to dsymutil
- Name -arch=<arch> argument
Differential revision: https://reviews.llvm.org/D39561
llvm-svn: 317226
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The original change was reverted in rL317217 because of the failure in
the RS4GC testcase. I couldn't reproduce the failure on my local machine
(macbook) but could reproduce it on a linux box.
The failure was around removing the uses of invariant.start. The fix
here is to just RAUW undef (which was the first implementation in D39388).
This is perfectly valid IR as discussed in the review.
llvm-svn: 317225
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39395
llvm-svn: 317223
|