Summary:
If one of the uses of the value is a single edge PHINode, handle it.
Original:
%val = something
<suspend>
%p = PHINode [%val]
After Spill + Part13:
%val = something
%slot = gep val.spill.slot
store %val, %slot
<suspend>
%p = load %slot
Plus tiny fixes/changes:
* use correct index for coro.free in CoroCleanup
* fixup id parameter in coro.free to allow authoring coroutine in plain C with __builtins
Reviewers: majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281020 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
While woring on mapping attributes in the C API, it clearly appeared that the recent changes in the API on the C++ side left Function and Call/Invoke with an attribute API that grew in an ad hoc manner. This makes it difficult to work with it, because one doesn't know which overloads exists and which do not.
Make sure that getter/setter function exists for both enum and string version. Remove inconsistent getter/setter, unless they have many callsites.
This should make it easier to work with attributes in the future.
This doesn't change how attribute works.
Reviewers: bkramer, whitequark, mehdi_amini, void
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21514
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281019 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281011 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281009 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281008 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281006 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281005 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280995 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280992 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280981 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280979 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280978 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280977 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280971 91177308-0d34-0410-b5e6-96231b3b80d8
And associated commits, as they broke the Thumb bots.
This reverts commit r280935.
This reverts commit r280891.
This reverts commit r280888.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280967 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280964 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280952 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280951 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280949 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280935 91177308-0d34-0410-b5e6-96231b3b80d8
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... :/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280928 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280927 91177308-0d34-0410-b5e6-96231b3b80d8
Allow AND combines to use a vector splatted constant as well as a constant scalar.
Preliminary part of D24253.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280926 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280918 91177308-0d34-0410-b5e6-96231b3b80d8
