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

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

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

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