As detailed on PR45974 and D79987, getFauxShuffleMask is creating nodes on the fly to create shuffles with inputs the same size as the result, causing problems for hasOneUse() checks in later simplification stages.

Currently only combineX86ShufflesRecursively benefits from these widened inputs so I've begun moving the functionality there, and out of getFauxShuffleMask. This allows us to remove the widening from VBROADCAST and *EXTEND* faux shuffle cases.

This just leaves the INSERT_SUBVECTOR case in getFauxShuffleMask still creating nodes, which will require more extensive refactoring.

In some cases ScheduleDAGRRList has to add new nodes to resolve problems
with interfering physical registers. When new nodes are added, it
completely re-computes the topological order, which can take a long
time, but is unnecessary. We only add nodes one by one, and initially
they do not have any predecessors. So we can just insert them at the end
of the vector. Later we add predecessors, but the helper function
properly updates the topological order much more efficiently. With this
change, the compile time for the program below drops from 300s to 30s on
my machine.

    define i11129 @test1() {
      %L1 = load i11129, i11129* undef
      %B30 = ashr i11129 %L1, %L1
      store i11129 %B30, i11129* undef
      ret i11129 %L1
    }

This should be generally beneficial, as we can skip a large amount of
work. Theoretically there are some scenarios where we might not safe
much, e.g. when we add a dependency between the first and last node.
Then we would have to shift all nodes. But we still do not have to spend
the time re-computing the initial order.

Reviewers: MatzeB, atrick, efriedma, niravd, paquette

Reviewed By: paquette

Differential Revision: https://reviews.llvm.org/D59722

This case wll be failed on some machines which enable expensive-checks.

This reverts commit af3abbf7.

Differential Revision: https://reviews.llvm.org/D80813

Reviewers:
  rampitec, arsenm

Differential Revision:
  https://reviews.llvm.org/D80853

The types already match so TableGen is removing the bitconvert.

[X86] Add DAG combine to turn (v2i64 (scalar_to_vector (i64 (bitconvert (mmx))))) to MOVQ2DQ. Remove unneeded isel patterns.

We already had a DAG combine for (mmx (bitconvert (i64 (extractelement v2i64))))
to MOVDQ2Q.

Remove patterns for MMX_MOVQ2DQrr/MMX_MOVDQ2Qrr that use
scalar_to_vector/extractelement involving i64 scalar type with
v2i64 and x86mmx.

This code was repeated in two callers of CommitTargetLoweringOpt.
But CommitTargetLoweringOpt is also called from TargetLowering.
We should print a message for those calls to. So sink the
repeated code into CommitTargetLoweringOpt to catch those calls.

The type profile and isel pattern have this type declared as
being MVT::v2i64. But isel skips the explicit type check due to
the type profile.

PowerPC, PowerPC64 and x86-32 have production quality.
Mention Hexagon, RISC-V and SPARC V9.

Or adding `static`.

Qualifying definitions with `objdump::` comforms to the coding standards
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions

As noticed by dblaikie.

I don't know what code paths using reportError can cause stdout output
to be interleaved with stderr, so no test is added now.

Also drop an unneeded use of errs().fflush() in reportWarning().
I requested this in D64165.

The instruction is defined to only produce high result if both
destinations are the same. We can exploit this to avoid
unnecessarily clobbering a register.

In order to hide this from register allocation we use a pseudo
instruction and expand the result during MCInst creation.

Differential Revision: https://reviews.llvm.org/D80500

The test read from an uninitialized buffer which could cause the output
to be unpredictable.

The test is currently disabled so this won't actually change anything
until the test is re-enabled.

-Replace some ifs that should be impossible with asserts.
-Use X86::AddrDisp and X86::AddrNumOperands to make code more readable
-Use X86II::isKMasked/isKMergeMasked to do some operand skipping to remove or simplify switches

[X86] Factor constant pool comment printing out of the switch in X86AsmPrinter::emitInstruction. NFC

Pull the verbose asm check out of the cases and move it up to
the call of the new function.

rG7873376b fixes a build failure for allyesconfig.

The problem happened when the single exiting block doesn't dominate the
loop latch, then the immediate dominator of the exit block should not be
the exiting block after unrolling. As the exiting block of
different unrolled iteration can branch to the exit block, and the ith
exiting block doesn't dominate (i+1)th exiting block, the immediate
dominator of the exit block should not the nearest common dominator of
the exiting block and the loop latch of the same iteration.

Differential Revision: https://reviews.llvm.org/D80477

Summary: Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=42635 | readability-identifier-naming option MacroDefinitionCase should ignore macros passed as parameters. ]]

Reviewers: aaron.ballman, alexfh, gribozavr2, hokein

Reviewed By: aaron.ballman

Subscribers: xazax.hun, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D80631

Differential Revision: https://reviews.llvm.org/D80477.

Adds a simple fast-path check for the pattern:
v = load ptr
store v to ptr

I took the tests from the bugzilla post, I can add more if needed (but I think these should be sufficent).

Refs: https://bugs.llvm.org/show_bug.cgi?id=45795

Differential Revision: https://reviews.llvm.org/D79391

Summary:
It seems that when we rewrite a few rules to only build a dylib (i.e., when DYLIB_ONLY is set),
the rule for setting the CFLAGS for the dylib's object file compilation will no longer work. From what I can
see this is because in DYLIB_ONLY mode we pretend to compile the main executable so
the DYLIB_OBJECTS scope is actually never used.

This patch makes `-fPIC` unstopped if DYLIB_ONLY is set so that -fPIC actually ends up in the
CFLAGS for the dylib object file compilation.

The test for this is D80798 which only compiles on Linux with this patch.

Reviewers: friss, labath

Reviewed By: friss

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D80789

Currently, BasicAA does not exploit information about value ranges of
indexes. For example, consider the 2 pointers %a = %base and
%b = %base + %stride below, assuming they are used to access 4 elements.

If we know that %stride >= 4, we know the accesses do not alias. If
%stride is a constant, BasicAA currently gets that. But if the >= 4
constraint is encoded using an assume, it misses the NoAlias.

This patch extends DecomposedGEP to include an additional MinOtherOffset
field, which tracks the constant offset similar to the existing
OtherOffset, which the difference that it also includes non-negative
lower bounds on the range of the index value. When checking if the
distance between 2 accesses exceeds the access size, we can use this
improved bound.

For now this is limited to using non-negative lower bounds for indices,
as this conveniently skips cases where we do not have a useful lower
bound (because it is not constrained). We potential miss out in cases
where the lower bound is constrained but negative, but that can be
exploited in the future.

Reviewers: sanjoy, hfinkel, reames, asbirlea

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D76194

SafeStackColoring.cpp - remove includes directly defined in SafeStackColoring.h header. NFC.

CriticalAntiDepBreaker.cpp - remove includes directly defined in CriticalAntiDepBreaker.h header. NFC.

[TargetLowering] SimplifyDemandedBits - remove shift amount clamps from getValidShiftAmountConstant calls. NFC.

getValidShiftAmountConstant only returns a value if the shift amount is in range, so we don't need to check it again.

We are calling getValidShiftAmountConstant first followed by getValidMinimumShiftAmountConstant/getValidMaximumShiftAmountConstant if that failed. But both are used in the same way in ComputeNumSignBits and the Min/Max variants call getValidShiftAmountConstant internally anyhow.

[clang-format] [PR46130] When editing a file with unbalance {} the namespace comment fixer can incorrectly comment the wrong closing brace

Summary:
https://bugs.llvm.org/show_bug.cgi?id=46130   from Twitter https://twitter.com/ikautak/status/1265998988232159232

I have seen this myself many times.. if you have format on save and you work in an editor where you are constantly saving (:w muscle memory)

If you are in the middle of editing and somehow you've missed a { or } in your code, somewhere, often way below where you are at the bottom of your file the namespace comment fixer will have put the namespace on the previous closing brace.

This leads to you having to fix up the bottom of the file.

This revision prevents that happening by performing an initial pass of the tokens and simply counting the number of `{` and `}`  and ensuring they balance.

If they don't balance we don't do any namespace fixing as it will likely be unstable and incorrect.

Reviewed By: curdeius

Subscribers: cfe-commits

Tags: #clang, #clang-format

Differential Revision: https://reviews.llvm.org/D80830

We already have to include VersionTuple.h

MSVC seems to implicitly include this from <utility> but other toolchains don't

Move raw_ostream.h include to ArchitectureSet.cpp.