| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
This will make the depedence graph more accurate if an alias analysis
is provided. If nullptr is specified in its place, the behavior will
remain as it is currently.
llvm-svn: 255540
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following description is from http://reviews.llvm.org/D15481:
ICmpInst, GetElementPtrInst and PHINode have no anchor functions. This causes the vtable and the type info (if RTTI is enabled in user code) to be emitted in multiple translation units.
Before 3.7, the destructors were the key functions for these nodes, but they have been removed.
There have been discussions about this here: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html and here: http://lists.llvm.org/pipermail/llvm-dev/2015-December/092921.html.
Patch by Visoiu Mistrih Francis
llvm-svn: 255538
|
| |
|
|
|
|
|
| |
This will allow custom handling of packet finalization. The current
definition of endPacket will still perform the default finalization.
llvm-svn: 255537
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make sure to check that the destination type is sized.
A check was present but was incorrectly checking the source type
instead.
Patch by Amaury SECHET!
Differential Revision: http://reviews.llvm.org/D15264
llvm-svn: 255536
|
| |
|
|
| |
llvm-svn: 255535
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15343
llvm-svn: 255534
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The normalization may cause assertion failures on SystemZ and some out-of-tree
tests. The root cause is that unknown probabilities are materialized into known
ones by calling getSuccProbability(), which is then used to add another
successor to the same MBB which results in mixed known and unknown
probabilities. But currently those mixed probabilities cannot be normalized.
I will compose another patch to fix the root issue.
llvm-svn: 255530
|
| |
|
|
|
|
| |
Using `CI` is slightly misleading.
llvm-svn: 255529
|
| |
|
|
| |
llvm-svn: 255528
|
| |
|
|
| |
llvm-svn: 255527
|
| |
|
|
| |
llvm-svn: 255526
|
| |
|
|
|
|
|
|
|
| |
This patch adds the missing functionality in parsable
text format support for value profiling.
Differential Revision: http://reviews.llvm.org/D15212
llvm-svn: 255523
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MSVC doesn't support them which
makes terminatepad a little over-designed.
Depends on D15478.
Differential Revision: http://reviews.llvm.org/D15479
llvm-svn: 255522
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When FastISel fails to translate an instruction it hands off code
generation to SelectionDAG. Before it does so, it may have generated
local value instructions to feed phi nodes in successor blocks. These
instructions will then be generated again by SelectionDAG, causing
duplication and less efficient code, including extra spill
instructions.
Patch by Wolfgang Pieb!
Differential Revision: http://reviews.llvm.org/D11768
llvm-svn: 255520
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the second in a set of patches for soft float support for ppc32,
it enables soft float operations.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D13700
llvm-svn: 255516
|
| |
|
|
|
|
| |
Also fix bug in vector legalization for bitreverse.
llvm-svn: 255512
|
| |
|
|
| |
llvm-svn: 255511
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, jmolloy, mcrosier
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D15458
llvm-svn: 255509
|
| |
|
|
|
|
|
| |
If the original MMO had an offset, it was dropped.
Also use the correct alignment after adding the new offset.
llvm-svn: 255508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for PR25543:
https://llvm.org/bugs/show_bug.cgi?id=25543
The idea is to take the existing fold of:
bitcast ( trunc ( lshr ( bitcast X))) --> extractelement (bitcast X)
( http://reviews.llvm.org/rL112232 )
And break it into less specific transforms so we'll catch more cases such as
the example in the bug report:
bitcast ( trunc ( lshr ( bitcast X))) -->
bitcast ( extractelement (bitcast X)) -->
extractelement (bitcast X)
Enabling patches for this change:
http://reviews.llvm.org/rL255399 (combine bitcasts)
http://reviews.llvm.org/rL255433 (canonicalize extractelement(bitcast X))
Differential Revision: http://reviews.llvm.org/D15392
llvm-svn: 255504
|
| |
|
|
| |
llvm-svn: 255501
|
| |
|
|
| |
llvm-svn: 255497
|
| |
|
|
|
|
|
|
| |
This patch add support for variadic argument for AArch64. All the MSAN
unit tests are not passing as well the signal_stress_test (currently
set as XFAIl for aarch64).
llvm-svn: 255495
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In conditional store merging, we were creating PHIs when we didn't
need to. If the value to be predicated isn't defined in the block
we're predicating, then it doesn't need a PHI at all (because we only
deal with triangles and diamonds, any value not in the predicated BB
must dominate the predicated BB).
This fixes a large code size increase in some benchmarks in a popular embedded benchmark suite.
llvm-svn: 255489
|
| |
|
|
| |
llvm-svn: 255483
|
| |
|
|
|
|
|
|
| |
It's O(N^2) because it does a simple walk through the existing types to
find duplicates, but that will be fixed in a follow-up commit to use a
mapping data structure of some kind.
llvm-svn: 255482
|
| |
|
|
| |
llvm-svn: 255481
|
| |
|
|
| |
llvm-svn: 255480
|
| |
|
|
|
|
|
|
| |
Continue of rL255461
Differential Revision: http://reviews.llvm.org/D15413
llvm-svn: 255469
|
| |
|
|
|
|
| |
Further investigation on the failures is ongoing.
llvm-svn: 255463
|
| |
|
|
|
|
|
|
|
|
|
| |
The .even directive aligns content to an evan-numbered address.
In at&t syntax .even
In Microsoft syntax even (without the dot).
Differential Revision: http://reviews.llvm.org/D15413
llvm-svn: 255462
|
| |
|
|
|
|
| |
template type.
llvm-svn: 255461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ignoring specific instructions.
(This is the second attempt to check in this patch: REQUIRES: asserts is added
to reg-usage.ll now.)
LoopVectorizationCostModel::calculateRegisterUsage() is used to estimate the
register usage for specific VFs. However, it takes into account many
instructions that won't be vectorized, such as induction variables,
GetElementPtr instruction, etc.. This makes the loop vectorizer too conservative
when choosing VF. In this patch, the induction variables that won't be
vectorized plus GetElementPtr instruction will be added to ValuesToIgnore set
so that their register usage won't be considered any more.
Differential revision: http://reviews.llvm.org/D15177
llvm-svn: 255460
|
| |
|
|
| |
llvm-svn: 255459
|
| |
|
|
| |
llvm-svn: 255458
|
| |
|
|
| |
llvm-svn: 255457
|
| |
|
|
| |
llvm-svn: 255456
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds some missing calls to MBB::normalizeSuccProbs() in several
locations where it should be called. Those places are found by checking if the
sum of successors' probabilities is approximate one in MachineBlockPlacement
pass with some instrumented code (not in this patch).
Differential revision: http://reviews.llvm.org/D15259
llvm-svn: 255455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ignoring specific instructions.
LoopVectorizationCostModel::calculateRegisterUsage() is used to estimate the
register usage for specific VFs. However, it takes into account many
instructions that won't be vectorized, such as induction variables,
GetElementPtr instruction, etc.. This makes the loop vectorizer too conservative
when choosing VF. In this patch, the induction variables that won't be
vectorized plus GetElementPtr instruction will be added to ValuesToIgnore set
so that their register usage won't be considered any more.
Differential revision: http://reviews.llvm.org/D15177
llvm-svn: 255454
|
| |
|
|
|
|
|
| |
EABI attributes should only be emitted on EABI targets. This prevents the
emission of the optimization goals EABI attribute on Windows ARM.
llvm-svn: 255448
|
| |
|
|
|
|
|
|
| |
It doesn't build on Windows and broke the Windows LLD and LLDB bots:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/27693/steps/build_Lld/logs/stdio
http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/13468/steps/build/logs/stdio
llvm-svn: 255446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.
In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.
This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.
Differential Revision: http://reviews.llvm.org/D15464
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255444
|
| |
|
|
| |
llvm-svn: 255443
|
| |
|
|
| |
llvm-svn: 255442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
construction if address space != 0.
Summary:
Previously SelectionDAGBuilder asserted that the pointer operands of
memcpy / memset / memmove intrinsics are in address space < 256. This assert
implicitly assumed the X86 backend, where all address spaces < 256 are
equivalent to address space 0 from the code generator's point of view. On some
targets (R600 and NVPTX) several address spaces < 256 have a target-defined
meaning, so this assert made little sense for these targets.
This patch removes this wrong assertion and adds extra checks before lowering
these intrinsics to library calls. If a pointer operand can't be casted to
address space 0 without changing semantics, a fatal error is reported to the
user.
The new behavior should be valid for all targets that give address spaces != 0
a target-specified meaning (NVPTX, R600, X86). NVPTX lowers big or
variable-sized memory intrinsics before SelectionDAG construction. All other
memory intrinsics are inlined (the threshold is set very high for this target).
R600 doesn't support memcpy / memset / memmove library calls (previously the
illegal emission of a call to such library function triggered an error
somewhere in the code generator). X86 now emits inline loads and stores for
address spaces 256 and 257 up to the same threshold that is used for address
space 0 and reports a fatal error otherwise.
I call this a "partial fix" because there are still cases that can't be
lowered. A fatal error is reported in these cases.
Reviewers: arsenm, theraven, compnerd, hfinkel
Subscribers: hfinkel, llvm-commits, alex
Differential Revision: http://reviews.llvm.org/D7241
llvm-svn: 255441
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specified when the file contains
any static functions (the -S output is also invalid).
This is the second try. The fix in this patch is very localized.
Only profile symbol names of profile symbols with internal
linkage are fixed up while initializer of name syms are not
changes. This means there is no format change nor version bump.
llvm-svn: 255434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(extractelement(bitcast X))
This change was discussed in D15392. It allows us to remove the fold that was added
in:
http://reviews.llvm.org/r255261
...and it will allow us to generalize this fold:
http://reviews.llvm.org/rL112232
while preserving the order of bitcast + extract that it produces and testing shows
is better handled by the backend.
Note that the existing check for "isVectorTy()" wasn't strong enough in general
and specifically because: x86_mmx. It's not a vector, but it's not vectorizable
either. So here we check VectorType::isValidElementType() directly before
proceeding with the transform.
llvm-svn: 255433
|
| |
|
|
|
|
| |
Cleanup/regenerate some tests for some upcoming patches.
llvm-svn: 255432
|
| |
|
|
| |
llvm-svn: 255429
|
| |
|
|
|
|
|
| |
It is X86 specific and will not be properly exercised unless LLVM is
built with the X86 target.
llvm-svn: 255426
|