| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
show opportunities where we can commute to fold loads.
Commutes will be added in a followup commit.
llvm-svn: 281012
|
| |
|
|
|
|
|
|
| |
llvm-cov writes out an index file in '-output-dir' mode, albeit not a
very informative one. Try to fix that by using the CoverageReport API to
include some basic summary information in the index file.
llvm-svn: 281011
|
| |
|
|
| |
llvm-svn: 281010
|
| |
|
|
|
|
|
|
| |
It would be nice to prepare file reports (using the CoverageReport API)
without actually rendering them to the console. I plan on using this to
flesh out the 'index' files in the coverage views.
llvm-svn: 281009
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This test should have broken after r280896. Fix up the test case
speculatively, since I don't have a way to test it.
I wonder why I didn't get any angry bot emails about this. Maybe none of
the win32 bots test llvm-cov? That could explain it, since the test says
it 'REQUIRES: system-windows', which is restricted to win32 hosts.
Also: why is 'system-windows' not defined for non-win32 Windows bots?
llvm-svn: 281008
|
| |
|
|
|
|
| |
better
llvm-svn: 281007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x64 ABI has two major function types:
- frame functions
- leaf functions
A frame function is one which requires a stack frame. A leaf function
is one which does not. A frame function may or may not have a frame
pointer.
A leaf function does not require a stack frame and may never modify SP
except via a return (RET, tail call via JMP).
A frame function which has a frame pointer is permitted to use the LEA
instruction in the epilogue, a frame function without which doesn't
establish a frame pointer must use ADD to adjust the stack pointer epilogue.
Fun fact: Leaf functions don't require a function table entry
(associated PDATA/XDATA).
llvm-svn: 281006
|
| |
|
|
|
|
|
| |
This adds more tests for shuffles where the output width does not match
the input width and/or the output is generated from more than two inputs.
llvm-svn: 281005
|
| |
|
|
|
|
|
|
|
|
| |
The REX prefix should be used on indirect jmps, but not direct ones.
For direct jumps, the unwinder looks at the offset to determine if
it's inside the current function.
Differential Revision: https://reviews.llvm.org/D24359
llvm-svn: 281003
|
| |
|
|
|
|
|
|
| |
Summary: Not sure why is it missing.
Differential Revision: https://reviews.llvm.org/D24364
llvm-svn: 281002
|
| |
|
|
|
|
| |
Add a missing ')' in the help output. NFC.
llvm-svn: 281000
|
| |
|
|
| |
llvm-svn: 280996
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The hoisted instruction is executed speculatively. It could affect the debugging experience as user would see gdb go into code that may not be expected to execute. It will also affect sample profile accuracy by assigning incorrect frequency to source within then/else branch.
Reviewers: davidxl, dblaikie, chandlerc, kcc, echristo
Subscribers: mehdi_amini, probinson, eric_niebler, andreadb, llvm-commits
Differential Revision: https://reviews.llvm.org/D24164
llvm-svn: 280995
|
| |
|
|
| |
llvm-svn: 280993
|
| |
|
|
|
|
|
|
|
|
|
| |
The test case included in r280979 wasn't checking what it was supposed to be
checking for the predicated store case. Fixing the test revealed that the
multi-use case (when a pointer is used by both vectorized and scalarized memory
accesses) wasn't being handled properly. We can't skip over
non-consecutive-like pointers since they may have looked consecutive-like with
a different memory access.
llvm-svn: 280992
|
| |
|
|
| |
llvm-svn: 280991
|
| |
|
|
| |
llvm-svn: 280987
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The text and html coverage views take different approaches to emitting
highlighted regions. That's because this problem is easier in the text
view: there's no need to worry about escaping text or adding tooltip
content to a highlighted snippet.
Unfortunately, the html view didn't get region highlighting quite right.
This patch fixes the situation, bringing parity between the two views.
llvm-svn: 280981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all consecutive pointers were marked uniform after vectorization.
However, if a consecutive pointer is used by a memory access that is eventually
scalarized, the pointer won't remain uniform after all. An example is
predicated stores. Even though a predicated store may be consecutive, it will
still be scalarized, making it's pointer operand non-uniform.
This patch updates the logic in collectLoopUniforms to consider the cases where
a memory access may be scalarized. If a memory access may be scalarized, its
pointer operand is not marked uniform. The determination of whether a given
memory instruction will be scalarized or not has been moved into a common
function that is used by the vectorizer, cost model, and legality analysis.
Differential Revision: https://reviews.llvm.org/D24271
llvm-svn: 280979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were making new instances of YamlTypeDumperCallbacks
in order to recurse down and serialize / deserialize nested
records such as field lists. This meant you could not pass
context from a higher operation to a lower operation because
it would be using a new instance of the visitor callback
delegate.
YAMLIO library was updated to support context-sensitive mappings,
so now we can reuse the same instance of the visitor callback
delegate even for nested operations.
llvm-svn: 280978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mapping a yaml field to an object in code has always been
a stateless operation. You could still pass state by using the
`setContext` function of the YAMLIO object, but this represented
global state for the entire yaml input. In order to have
context-sensitive state, it is necessary to pass this state in
at the granularity of an individual mapping.
This patch adds support for this type of context-sensitive state.
You simply pass an additional argument of type T to the
`mapRequired` or `mapOptional` functions, and provided you have
specialized a `MappingContextTraits<U, T>` class with the
appropriate mapping function, you can pass this context into
the mapping function.
Reviewed By: chandlerc
Differential Revision: https://reviews.llvm.org/D24162
llvm-svn: 280977
|
| |
|
|
|
|
|
| |
This will confuse later passes which try to look at the
immediate value and don't truncate first.
llvm-svn: 280974
|
| |
|
|
|
|
| |
Recent change exposed this issue, breaking the Hexagon buildbots.
llvm-svn: 280973
|
| |
|
|
| |
llvm-svn: 280972
|
| |
|
|
|
|
|
|
| |
Fix the .arch asm parser to use the full set of features for the architecture
and any extensions on the command line. Add and update testcases accordingly
as well as add an extension that was used but not supported.
llvm-svn: 280971
|
| |
|
|
| |
llvm-svn: 280970
|
| |
|
|
|
|
|
|
|
|
| |
And associated commits, as they broke the Thumb bots.
This reverts commit r280935.
This reverts commit r280891.
This reverts commit r280888.
llvm-svn: 280967
|
| |
|
|
|
|
|
| |
Switch to range based for loop.
No functional change, but more readable code.
llvm-svn: 280966
|
| |
|
|
|
|
|
|
|
|
|
| |
I introduced this potential bug by missing this diff in:
https://reviews.llvm.org/rL280873
...however, I'm not sure how to reach this code path with a regression test.
We may be able to remove this code and assume that the transform to a constant
is always handled by InstSimplify?
llvm-svn: 280964
|
| |
|
|
| |
llvm-svn: 280963
|
| |
|
|
| |
llvm-svn: 280960
|
| |
|
|
| |
llvm-svn: 280959
|
| |
|
|
| |
llvm-svn: 280957
|
| |
|
|
| |
llvm-svn: 280956
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows specifying instructions that are available only in specific assembler variant. If AsmVariantName is specified then instruction will be presented only in MatchTable for this variant. If not specified then assembler variants will be determined based on AsmString.
Also this allows splitting assembler match tables in same way as it is done in dissasembler.
Reviewers: ab, tstellarAMD, craig.topper, vpykhtin
Subscribers: wdng
Differential Revision: https://reviews.llvm.org/D24249
llvm-svn: 280952
|
| |
|
|
|
|
|
|
|
|
| |
On Windows, it is often applied to the second parameter, and the x86
backend is prepared to deal with sret appearing on any parameter.
Other backends assume it only appears on parameter zero, but those are
target-specific requirements, and not an IR-level rule.
llvm-svn: 280951
|
| |
|
|
| |
llvm-svn: 280950
|
| |
|
|
|
|
|
| |
Refactor replaceDominatedUsesWith to have a flag to control whether to replace uses in BB itself.
Summary: This is in preparation for LoopSink pass which calls replaceDominatedUsesWith to update after sinking.
llvm-svn: 280949
|
| |
|
|
|
|
|
| |
I mised the check that it had to support ARM to work. This commit tries
to fix that, to make sure we don't emit ARM code in Thumb-only mode.
llvm-svn: 280935
|
| |
|
|
|
|
| |
This bloats codesize - all of the non-leaf nodes are extra code.
llvm-svn: 280932
|
| |
|
|
|
|
|
| |
So model the cost of materializing the constant operand C as the minimum of
C and ~C.
llvm-svn: 280929
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Materializing something like "-3" can be done as 2 instructions:
MOV r0, #3
MVN r0, r0
This has a cost of 2, not 3. It looks like we were already trying to detect this pattern in TII::getIntImmCost(), but were taking the complement of the zero-extended value instead of the sign-extended value which is unlikely to ever produce a number < 256.
There were no tests failing after changing this... :/
llvm-svn: 280928
|
| |
|
|
|
|
|
|
|
|
|
|
| |
SimplifyDemandedBits
Add the ability to computeKnownBits and SimplifyDemandedBits to extract the known zero/one bits from BUILD_VECTOR, returning the known bits that are shared by every vector element.
This is an initial step towards determining the sign bits of a vector (PR29079).
Differential Revision: https://reviews.llvm.org/D24253
llvm-svn: 280927
|
| |
|
|
|
|
|
|
| |
Allow AND combines to use a vector splatted constant as well as a constant scalar.
Preliminary part of D24253.
llvm-svn: 280926
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit r280808.
It is possible that this change results in an infinite loop. This
is causing timeouts in some tests on ARM, and a Chromebook bot is
failing.
llvm-svn: 280918
|
| |
|
|
|
|
|
|
| |
instructions
Differential Revision: https://reviews.llvm.org/D16452
llvm-svn: 280909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C allows to jump over variables declaration so lifetime.start can be
avoid before variable usage. To avoid false-positives on such rare cases
we detect them and remove from lifetime analysis.
PR27453
PR28267
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24321
llvm-svn: 280907
|
| |
|
|
|
|
|
|
|
|
| |
epilogues."
This reverts commit r280901.
This caused a bunch of failures, reverting it until I investigate them.
llvm-svn: 280905
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When cloning blocks for prologue/epilogue we need to replicate the loop
structure from the original loop. It wasn't a problem for the innermost
loops, but it led to an incorrect loop info when we unrolled a loop with
a child loop - in this case created prologue-loop had a child loop, but
loop info didn't reflect that.
This fixes PR28888.
Reviewers: chandlerc, sanjoy, hfinkel
Subscribers: llvm-commits, silvas
Differential Revision: https://reviews.llvm.org/D24203
llvm-svn: 280901
|
| |
|
|
|
|
|
|
|
|
| |
Disable name compression in the inputs used to produce
multiple-files.covmapping. Should fix bots which don't compile with
zlib:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/19610/steps/test/logs/stdio
llvm-svn: 280898
|