| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Also remove an executable bit introduced by r258083.
llvm-svn: 258101
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
globalize any local variables.
Summary:
Currently llvm::SplitModule as the first step globalizes all local objects, which might not be desirable in some scenarios.
This change adds a new flag to llvm::SplitModule that uses SCC approach to search for a balanced partition without the need to externalize symbols.
Such partition might not be possible or fully balanced for a given number of partitions, and is a function of the module properties (global/local dependencies within the module).
Joint development Tobias Edler von Koch (tobias@codeaurora.org) and Sergei Larin (slarin@codeaurora.org)
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D16124
llvm-svn: 258083
|
| |
|
|
| |
llvm-svn: 258062
|
| |
|
|
| |
llvm-svn: 258059
|
| |
|
|
| |
llvm-svn: 258058
|
| |
|
|
| |
llvm-svn: 258057
|
| |
|
|
|
|
| |
in address space.
llvm-svn: 258029
|
| |
|
|
|
|
|
|
|
|
|
|
| |
getType()->getPointerElementType().
Reviewers: mjacob
Subscribers: llvm-commits, dblaikie
Differential Revision: http://reviews.llvm.org/D16272
llvm-svn: 258028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
source element type of the GEP as an argument.
Patch by Eduard Burtescu.
Reviewers: dblaikie, mjacob
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16281
llvm-svn: 258024
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`LCSSASafePhiForRAUW` as computed was incorrect -- in cases like
these (this exact example does not actually trigger the bug):
define i32 @f(i32 %n, i1* %c) {
entry:
br label %outer.loop
outer.loop:
br label %inner.loop
inner.loop:
%iv = phi i32 [ 0, %outer.loop ], [ %iv.inc, %inner.loop ]
%iv.inc = add nuw nsw i32 %iv, 1
%tc = udiv i32 %n, 13
%be.cond = icmp ult i32 %iv, %tc
br i1 %be.cond, label %inner.loop, label %inner.exit
inner.exit:
%iv.lcssa = phi i32 [ %iv, %inner.loop ]
%outer.be.cond = load volatile i1, i1* %c
br i1 %outer.be.cond, label %outer.loop, label %leave
leave:
%iv.lcssa.lcssa = phi i32 [ %iv.lcssa, %inner.exit ]
ret i32 %iv.lcssa.lcssa
}
`LCSSASafePhiForRAUW` is true for `%iv.lcssa` when re-rewriting the exit
value of `%iv` for `%inner.loop` to `%tc` (this can happen due to
`SCEVExpander::findExistingExpansion`), but the RAUW breaks LCSSA.
To fix this, instead of computing `SafePhi` with special logic, decide
the safety of RAUW directly via `replacementPreservesLCSSAForm`.
llvm-svn: 258016
|
| |
|
|
| |
llvm-svn: 258015
|
| |
|
|
| |
llvm-svn: 258011
|
| |
|
|
|
|
|
|
| |
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D16226
llvm-svn: 258010
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mjacob
Subscribers: jholewinski, arsenm, dsanders, dblaikie
Patch by Eduard Burtescu.
Differential Revision: http://reviews.llvm.org/D16260
llvm-svn: 257999
|
| |
|
|
|
|
|
|
|
| |
This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.
Differential Revision: http://reviews.llvm.org/D16174
llvm-svn: 257970
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I mentioned the issue here in code review way back in September and
was sure we'd fixed it, but apparently we forgot:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301850.html
In any case, as soon as you try to use this pass in anything but the
most basic pipeline everything falls apart. Fix the condition.
llvm-svn: 257935
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix uniques the bundle of getelementptr indices we are about to vectorize
since it's possible for the same index to be used by multiple instructions.
The original commit message is below.
[SLP] Vectorize the index computations of getelementptr instructions.
This patch seeds the SLP vectorizer with getelementptr indices. The primary
motivation in doing so is to vectorize gather-like idioms beginning with
consecutive loads (e.g., g[a[0] - b[0]] + g[a[1] - b[1]] + ...). While these
cases could be vectorized with a top-down phase, seeding the existing bottom-up
phase with the index computations avoids the complexity, compile-time, and
phase ordering issues associated with a full top-down pass. Only bundles of
single-index getelementptrs with non-constant differences are considered for
vectorization.
llvm-svn: 257918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
platforms.
With ELF, the alignment of a global variable in a shared library will
get copied into an executables linked against it, if the executable even
accesss the variable. So, it's not possible to implicitly increase
alignment based on access patterns, or you'll break existing binaries.
This happened to affect libc++'s std::cout symbol, for example. See
thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311
(This is a re-commit of r257719, without the bug reported in
PR26144. I've tweaked the code to not assert-fail in
enforceKnownAlignment when computeKnownBits doesn't recurse far enough
to find the underlying Alloca/GlobalObject value.)
Differential Revision: http://reviews.llvm.org/D16145
llvm-svn: 257902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This contains a fix for the issue that caused the revert:
we no longer assume that we can insert instructions after the
instruction that produces the base pointer. We previously
assumed that this would be ok, because the instruction produces
a value and therefore is not a terminator. This is false for invoke
instructions. We will now insert these new instruction directly
at the location of the users.
Original commit message:
[InstCombine] Look through PHIs, GEPs, IntToPtrs and PtrToInts to expose more constants when comparing GEPs
Summary:
When comparing two GEP instructions which have the same base pointer
and one of them has a constant index, it is possible to only compare
indices, transforming it to a compare with a constant. This removes
one use for the GEP instruction with the constant index, can reduce
register pressure and can sometimes lead to removing the comparisson
entirely.
InstCombine was already doing this when comparing two GEPs if the base
pointers were the same. However, in the case where we have complex
pointer arithmetic (GEPs applied to GEPs, PHIs of GEPs, conversions to
or from integers, etc) the value of the original base pointer will be
hidden to the optimizer and this transformation will be disabled.
This change detects when the two sides of the comparison can be
expressed as GEPs with the same base pointer, even if they don't
appear as such in the IR. The transformation will convert all the
pointer arithmetic to arithmetic done on indices and all the relevant
uses of GEPs to GEPs with a common base pointer. The GEP comparison
will be converted to a comparison done on indices.
Reviewers: majnemer, jmolloy
Subscribers: hfinkel, jevinskie, jmolloy, aadg, llvm-commits
Differential Revision: http://reviews.llvm.org/D15146
llvm-svn: 257897
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D10920.
llvm-svn: 257894
|
| |
|
|
|
|
| |
This reverts commit r257800.
llvm-svn: 257888
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several requirements that ended up with this design;
1. Matching bitreversals is too heavyweight for InstCombine and doesn't really need to be done so early.
2. Bitreversals and byteswaps are very related in their matching logic.
3. We want to implement support for matching more advanced bswap/bitreverse patterns like partial bswaps/bitreverses.
4. Bswaps are best matched early in InstCombine.
The result of these is that a new utility function is created in Transforms/Utils/Local.h that can be configured to search for bswaps, bitreverses or both. InstCombine uses it to find only bswaps, CGP uses it to find only bitreversals.
We can then extend the matching logic in one place only.
llvm-svn: 257875
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15401
llvm-svn: 257832
|
| |
|
|
| |
llvm-svn: 257804
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch seeds the SLP vectorizer with getelementptr indices. The primary
motivation in doing so is to vectorize gather-like idioms beginning with
consecutive loads (e.g., g[a[0] - b[0]] + g[a[1] - b[1]] + ...). While these
cases could be vectorized with a top-down phase, seeding the existing bottom-up
phase with the index computations avoids the complexity, compile-time, and
phase ordering issues associated with a full top-down pass. Only bundles of
single-index getelementptrs with non-constant differences are considered for
vectorization.
Differential Revision: http://reviews.llvm.org/D14829
llvm-svn: 257800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If SROA creates only one piece (e.g. because the other is not needed),
it still needs to create a bit_piece expression if that bit piece is smaller
than the original size of the alloca.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16187
llvm-svn: 257795
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The dbg.declare -> dbg.value conversion did not check which operand of
the store instruction the alloca was passed to. As a result code that stored the
address of an alloca, rather than storing to the alloca, would still trigger
the conversion routine, leading to the insertion of an incorrect dbg.value
intrinsic.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16169
llvm-svn: 257787
|
| |
|
|
|
|
|
|
| |
platforms."
This reverts commit r257719, due to PR26144.
llvm-svn: 257775
|
| |
|
|
|
|
| |
Loop trip counts can often be resolved during LTO. We should obviously be unrolling small loops once those trip counts have been resolved, but we weren't.
llvm-svn: 257767
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The overloads of CallInst::Create and InvokeInst::Create that are used to
adjust operand bundles purport to create a new instruction "identical in
every way except [for] the operand bundles", so copy the DebugLoc along
with everything else.
Reviewers: sanjoy, majnemer
Subscribers: majnemer, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16157
llvm-svn: 257745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
platforms.
With ELF, the alignment of a global variable in a shared library will
get copied into an executables linked against it, if the executable even
accesss the variable. So, it's not possible to implicitly increase
alignment based on access patterns, or you'll break existing binaries.
This happened to affect libc++'s std::cout symbol, for example. See
thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311
llvm-svn: 257719
|
| |
|
|
| |
llvm-svn: 257700
|
| |
|
|
|
|
| |
Also, improve variable name and remove unnecessary braces.
llvm-svn: 257687
|
| |
|
|
| |
llvm-svn: 257677
|
| |
|
|
| |
llvm-svn: 257578
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The dbg.declare -> dbg.value conversion looks through any zext/sext
to find a value to describe the variable (in the expectation that those
zext/sext instruction will go away later). However, those values do not
cover the entire variable and thus need a DW_OP_bit_piece.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16061
llvm-svn: 257534
|
| |
|
|
|
|
|
|
| |
pow(x, 0.5) calls
Also, propagate the FMF to the newly created sqrt() call.
llvm-svn: 257503
|
| |
|
|
| |
llvm-svn: 257500
|
| |
|
|
| |
llvm-svn: 257496
|
| |
|
|
|
|
|
|
|
| |
The findExternalCalls routine ignores calls to functions already
defined in the dest module. This was not handling the case where
the definition in the current module is actually an alias to a
function call.
llvm-svn: 257493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pow(exp(x)) calls
See also:
http://reviews.llvm.org/rL255555
http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964
http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404
http://reviews.llvm.org/rL257414
llvm-svn: 257491
|
| |
|
|
|
|
|
| |
This is pure code motion - break the actual work out of runOnLoop into
a reusable standalone function.
llvm-svn: 257445
|
| |
|
|
| |
llvm-svn: 257427
|
| |
|
|
|
|
|
|
|
|
| |
The layering of where the various loop unroll parameters are
initialized and overridden here was very confusing, making it pretty
difficult to tell just how the various sources interacted. Instead, we
put all of the initialization logic together in a single function so
that it's obvious what overrides what.
llvm-svn: 257426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, add tests to verify that we're checking 'fast' on both calls of each transform pair,
tighten the CHECK lines, and give the tests more meaningful names.
This is a continuation of:
http://reviews.llvm.org/rL255555
http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964
http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404
llvm-svn: 257414
|
| |
|
|
|
|
|
| |
Fix the FIXME added with:
http://reviews.llvm.org/rL257400
llvm-svn: 257404
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently we're unrolling loops more in minsize than in optsize, which
means -Oz will have a larger code size than -Os. That doesn't make any
sense.
This resolves the FIXME about this in LoopUnrollPass and extends the
optsize test to make sure we use the smaller threshold for minsize as
well.
llvm-svn: 257402
|
| |
|
|
| |
llvm-svn: 257401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls
This is a continuation of adding FMF to call instructions:
http://reviews.llvm.org/rL255555
The intent of the patch is to preserve the current behavior of the transform except
that we use the sqrt instruction's 'fast' attribute as a trigger rather than the
function-level attribute.
But this raises a bug noted by the new FIXME comment.
In order to do this transform:
sqrt((x * x) * y) ---> fabs(x) * sqrt(y)
...we need all of the sqrt, the first fmul, and the second fmul to be 'fast'.
If any of those ops is strict, we should bail out.
Differential Revision: http://reviews.llvm.org/D15937
llvm-svn: 257400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Address review feedback from r255909.
Move body of resolveCycles(bool AllowTemps) to
resolveRecursivelyImpl(bool AllowTemps). Revert resolveCycles back
to asserting on temps, and add new resolveNonTemporaries interface
to invoke the new implementation with AllowTemps=true. Document
the differences between these interfaces, specifically the effect
on RAUW support and uniquing. Call appropriate interface from
ValueMapper.
llvm-svn: 257389
|