| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 237398
|
| |
|
|
|
|
|
|
| |
This is to cleanup some redundency generated by LoopUnroll pass. Such redundency may not be cleaned up by existing passes after LoopUnroll.
Differential Revision: http://reviews.llvm.org/D9777
llvm-svn: 237395
|
| |
|
|
|
|
|
| |
This ends up being a copy. Pointy hat to me.
Reported by: dexonsmith, dblaikie
llvm-svn: 237394
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit r237314 that implements YAML block parsing
introduced a leak that was caught by the ASAN linux buildbot.
YAML Parser stores its tokens in an ilist, and allocates
tokens using a BumpPtrAllocator, but doesn't call the
destructor for the allocated tokens. R237314 added an
std::string field to a Token which leaked as the Token's
destructor wasn't called. This commit fixes this leak
by calling the Token's destructor when a Token is being
removed from an ilist of tokens.
llvm-svn: 237389
|
| |
|
|
|
|
|
|
|
| |
The induction variable in the vectorized loop wasn't
recognized properly, so a hardware loop wasn't generated.
Differential Revision: http://reviews.llvm.org/D9722
llvm-svn: 237388
|
| |
|
|
| |
llvm-svn: 237379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function 'ConstantFoldScalarCall' (in ConstantFolding.cpp) works under the
wrong assumption that a call to 'convert.from.fp16' returns a value of
type 'float'.
However, intrinsic 'convert.from.fp16' can be overloaded; for example, we
can call 'convert.from.fp16.f64' to convert from half to double; etc.
Before this patch, the following example would have triggered an assertion
failure in opt (with -constprop):
```
define double @foo() {
entry:
%0 = call double @llvm.convert.from.fp16.f64(i16 0)
ret double %0
}
```
This patch fixes the problem in ConstantFolding.cpp. When folding a call to
convert.from.fp16, we perform a different kind of conversion based on the call
return type.
Added test 'Transform/ConstProp/convert-from-fp16.ll'.
Differential Revision: http://reviews.llvm.org/D9771
llvm-svn: 237377
|
| |
|
|
| |
llvm-svn: 237376
|
| |
|
|
| |
llvm-svn: 237375
|
| |
|
|
|
|
|
|
|
|
|
| |
After converting a loop to a hardware loop, the pass should remove
any unnecessary instructions from the old compare-and-branch
code. This patch removes a dead constant assignment that was
used in the compare instruction.
Differential Revision: http://reviews.llvm.org/D9720
llvm-svn: 237373
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9752
llvm-svn: 237367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When used, ".set nomacro" causes warning messages to be reported when we expand pseudo-instructions to multiple machine instructions.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9564
llvm-svn: 237366
|
| |
|
|
|
|
|
|
| |
If the loop trip count may underflow or wrap, the compiler should
not generate a hardware loop since the trip count will be
incorrect.
llvm-svn: 237365
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9563
llvm-svn: 237363
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we are trying to fill the delay slot of a call instruction, we must avoid
filler instructions that use the $ra register. This fixes the test
MultiSource/Applications/JM/lencod when we enable the forward delay slot filler.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9670
llvm-svn: 237362
|
| |
|
|
|
|
| |
No longer breaks SPEC2000/2006
llvm-svn: 237361
|
| |
|
|
| |
llvm-svn: 237359
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This implements the initial version as was proposed earlier this year
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/080462.html).
Since then Loop Access Analysis was split out from the Loop Vectorizer
and was made into a separate analysis pass. Loop Distribution becomes
the second user of this analysis.
The pass is off by default and can be enabled
with -enable-loop-distribution. There is currently no notion of
profitability; if there is a loop with dependence cycles, the pass will
try to split them off from other memory operations into a separate loop.
I decided to remove the control-dependence calculation from this first
version. This and the issues with the PDT are actively discussed so it
probably makes sense to treat it separately. Right now I just mark all
terminator instruction required which keeps identical CFGs for each
distributed loop. This seems to be working pretty well for 456.hmmer
where even though there is an empty if-then block in the distributed
loop initially, it gets completely removed.
The pass keeps DominatorTree and LoopInfo updated. I've tested this
with -loop-distribute-verify with the testsuite where we distribute ~90
loops. SimplifyLoop is violated in some cases and I have a FIXME
covering this.
Reviewers: hfinkel, nadav, aschwaighofer
Reviewed By: aschwaighofer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8831
llvm-svn: 237358
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9295
llvm-svn: 237356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we only pass the necessary operands, we don't have to determine the position of the symbol operand when entering expandLoadAddressSym().
This simplifies the expandLoadAddressSym() code.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9291
llvm-svn: 237355
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: echristo
Subscribers: llvm-commits
Follow-up to: http://reviews.llvm.org/D8496#158595
Relates to: http://reviews.llvm.org/rL235089
llvm-svn: 237354
|
| |
|
|
|
|
|
|
| |
i1 type is a legal type on AVX-512 and can be passed as parameter or return value.
i1 is promoted to i8 on return and to i32 for call arguments (i8 is also promoted to i32 here).
The result code is similar to the previous X86 targets, where i1 is allways promoted to i8.
llvm-svn: 237350
|
| |
|
|
|
|
|
|
| |
Found by ubsan. This was taking a bool and left shifting by 32 - the
result is 64 bit, so we should really do the math in a type it fits
in.
llvm-svn: 237345
|
| |
|
|
|
|
|
|
| |
functional change intended.
The outer if had 3 separate conditions ORed together and then the inner ifs detected which of the three conditions it was by using only a portion of the specific condition. Just put the whole condition in each inner if and remove the outer if.
llvm-svn: 237343
|
| |
|
|
| |
llvm-svn: 237342
|
| |
|
|
|
|
| |
if it was just comparing to 0. NFC.
llvm-svn: 237340
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9692
llvm-svn: 237327
|
| |
|
|
|
|
|
|
| |
Other targets probably should as well. Since r237161, compiler-rt has
both, but I don't see why anything other than gnueabi would use a
gnueabi naming scheme.
llvm-svn: 237324
|
| |
|
|
| |
llvm-svn: 237317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements the parsing of YAML block scalars.
Some code existed for it before, but it couldn't parse block
scalars.
This commit adds a new yaml node type to represent the block
scalar values.
This commit also deletes the 'spec-09-27' and 'spec-09-28' tests
as they are identical to the test file 'spec-09-26'.
This commit introduces 3 new utility functions to the YAML scanner
class: `skip_s_space`, `advanceWhile` and `consumeLineBreakIfPresent`.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D9503
llvm-svn: 237314
|
| |
|
|
|
|
| |
accessing it through the pointee's type
llvm-svn: 237312
|
| |
|
|
|
|
| |
it through the GV's pointee type
llvm-svn: 237311
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9110
llvm-svn: 237310
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ArrayRef already has a SFINAE constructor which can construct ArrayRef<const T*> from ArrayRef<T*>.
This adds methods to do the same directly from SmallVector and std::vector. This avoids an intermediate step through the use of makeArrayRef.
Also update the users of this in LICM and SROA to remove the now unnecessary makeArrayRef call.
Reviewed by David Blaikie.
llvm-svn: 237309
|
| |
|
|
|
|
|
|
|
|
| |
This version doesn't need begin/end but can instead just take a type which has begin/end methods.
Use this to replace an eligible foreach loop in LoopInfo found by David Blaikie in r237224.
Reviewed by David Blaikie.
llvm-svn: 237301
|
| |
|
|
|
|
|
|
|
|
| |
If we have a coverage mapping but no profile data for a function,
calling it mismatched is misleading. This can just as easily be
unreachable code that was stripped from the binary. Instead, treat
these the same as functions where we have an explicit "zero" coverage
map by setting the count to zero for each mapped region.
llvm-svn: 237298
|
| |
|
|
|
|
|
|
| |
There's no need to manually pass modifier strings around to tell an operand how
to print now, that information is encoded in the operand itself since the MC
layer came along.
llvm-svn: 237295
|
| |
|
|
|
|
|
|
| |
We were creating and propagating two separate indices for each jump table (from
back in the mists of time). However, the generic index used by other backends
is sufficient to emit a unique symbol so this was unneeded.
llvm-svn: 237294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous logic mixed 2 separate questions:
+ Can we form a TBB/TBH instruction?
+ Can we remove the jump-table calculation before it?
It then performed a bunch of random tests on the instructions earlier in the
basic block, which were probably sufficient to answer 2 but only because of the
very limited ways in which a t2BR_JT can actually be created.
For example there's no reason to expect the LeaInst to define the same base
register as the following indexing calulation. In practice this means we might
have missed opportunities to form TBB/TBH, in theory you could end up
misidentifying a sequence and removing the wrong LEA:
%R1 = t2LEApcrelJT ...
%R2 = t2LEApcrelJT ...
<... using and killing %R2 ...>
%R2 = t2ADDr %R1, $Ridx
Before we would have looked for an LEA defining %R2 and found the wrong one. We
just got lucky that jump table setup was (almost?) always confined to a single
basic block and there was only one jump table per block.
llvm-svn: 237293
|
| |
|
|
| |
llvm-svn: 237287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch teaches the PlaceSafepoints pass about two `CallSite`
function attributes:
* "statepoint-id": if the string value of this attribute can be parsed
as an integer, then it is propagated to the ID parameter of the
statepoint created.
* "statepoint-num-patch-bytes": if the string value of this attribute
can be parsed as an integer, then it is propagated to the `num patch
bytes` parameter of the statepoint created.
This change intentionally does not assert on a malformed value for these
attributes, given that they're not "official" attributes.
Reviewers: reames, pgavlin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9735
llvm-svn: 237286
|
| |
|
|
| |
llvm-svn: 237284
|
| |
|
|
|
|
| |
MCOperand::Create*() methods renamed to MCOperand::create*().
llvm-svn: 237275
|
| |
|
|
|
|
| |
pointee source type rather than going through the first operand's pointer type
llvm-svn: 237274
|
| |
|
|
|
|
| |
instruction constructor when parsing invoke instructions
llvm-svn: 237273
|
| |
|
|
| |
llvm-svn: 237272
|
| |
|
|
|
|
|
|
|
| |
Avoid running forever by checking we are not reassociating an expression into
the same form.
Tested with @avoid_infinite_loops in nary-add.ll
llvm-svn: 237269
|
| |
|
|
|
|
|
|
| |
loop1 is for the outer loop and loop0 is for the inner loop.
Differential Revision: http://reviews.llvm.org/D9680
llvm-svn: 237266
|
| |
|
|
|
|
|
|
|
|
| |
This patch uses the new function profile metadata "function_entry_count"
to annotate entry counts from sample profiles.
In a sampling profile, the total samples collected at the function entry
are an approximation for the number of times that function was invoked.
llvm-svn: 237265
|
| |
|
|
|
|
|
|
|
|
|
| |
Some compilers warn about using the ternary operator with an unsigned variable
and enum.
I haven't seen this trigger in the llvm.org buildbots yet, but it probably will
at some point.
Reported by Daniel Sanders.
llvm-svn: 237262
|