llvm-svn: 321585

Broadcast of sign/zero extended scalars resulting in unnecessary vector constants

llvm-svn: 321584

To compare against (v2f32 build_vector(f32 uitofp(i32), f32 uitofp(i32)))

llvm-svn: 321583

It caused buildbot fails.

llvm-svn: 321582

This was raised in comments for D41592.
With current code we always assign parent
section for Rel[a] sections like
InX::RelaPlt or InX::RelaDyn, so checking
their parent for null is excessive.

llvm-svn: 321581

Configuration file is read as a response file in which file names in
the nested constructs `@file` are resolved relative to the directory
where the including file resides. Lines in which the first non-whitespace
character is '#' are considered as comments and are skipped. Trailing
backslashes are used to concatenate lines in the same way as they
are used in shell scripts.

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

llvm-svn: 321580

If the callee and caller use different calling convensions, we cannot apply TCO if the callee requires arguments on stack; e.g. C calling convention and Fast CC use the same registers for parameter passing, but the stack offset is not necessarily same.

This patch also recommit r319218 "[PowerPC] Allow tail calls of fastcc functions from C CallingConv functions." by @sfertile since the problem reported in r320106 should be fixed.

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

llvm-svn: 321579

If using a version script with a `local: *` in it, symbols in shared
libraries will still get default visibility if another shared library on
the link line has an undefined reference to the symbol. This is quite
surprising. Neither bfd nor gold have this behavior when linking a
shared library, and none of LLD's tests fail without this behavior, so
it seems safe to limit scanShlibUndefined to executables.

As far as executables are concerned, gold doesn't do any automatic
default visibility marking, and bfd issues a link error about a shared
library having a reference to a hidden symbol rather than silently
giving that symbol default visibility. I think bfd's behavior here is
preferable to LLD's, but that's something to be considered in a
follow-up.

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

llvm-svn: 321578

We should only be creating natively supported kshifts now.

llvm-svn: 321577

This allows us to remove some isel patterns.

This is mostly NFC, but we now use KSHIFTB instead of KSHIFTW with DQI.

llvm-svn: 321576

[instsimplify] consistently handle undef and out of bound indices for insertelement and extractelement

In one case, we were handling out of bounds, but not undef indices.  In the other, we were handling undef (with the comment making the analogy to out of bounds), but not out of bounds.  Be consistent and treat both undef and constant out of bounds indices as producing undefined results.

As a side effect, this also protects instcombine from having to handle large constant indices as we always simplify first.

llvm-svn: 321575

llvm-svn: 321574

Went to reduce another fuzzer failure to find it's already been fixed, but the test case is slightly different so it's worth adding anyways.

Reduced from oss-fuzz #4768 test case

llvm-svn: 321573

llvm-svn: 321572

Fix code in LiveDebugVariables that was changing def MachineOperands to
uses, which will hit an assert for dead operands after the change to add
the renamable bit to MachineOperands.  Avoid the assert by clearing the
dead bit before changing the operand to a use.

Fixes issue reported in out of tree target by Jesper Antonsson at Ericsson.

llvm-svn: 321571

llvm-svn: 321570

llvm-svn: 321569

llvm-svn: 321568

llvm-svn: 321567

llvm-svn: 321566

Initially, if the `c` constraint applied to the wrong data type that
causes LLVM to assert. This commit replaces the assert by an error
message.

llvm-svn: 321565

llvm-svn: 321564

llvm-svn: 321563

llvm-svn: 321562

llvm-svn: 321561

only.

Added support for -fopenmp-simd option that allows compilation of
simd-based constructs without emission of OpenMP runtime calls.

llvm-svn: 321560

-target has no OS version

This ensures that Clang won't warn about redundant -m<os>-version-min
argument for an invocation like
`-target x86_64-apple-macos -mmacos-version-min=10.11`

llvm-svn: 321559

Added basic support for `-fopenmp-simd` options.

llvm-svn: 321558

Also fixes using the wrong memory type for some
intrinsics when custom lowering them.

llvm-svn: 321557

Atomics still have hasSideEffects set on them because
of the mess that is the memory properties.

llvm-svn: 321556

Currently all images are lowered to have a single
image PseudoSourceValue. Image stores happen to have
overly strict mayLoad/mayStore/hasSideEffects flags
set on them, so this happens to work. When these
are fixed to be correct, the scheduler breaks
this because the identical PSVs are assumed to
be the same address. These need to be unique
to the image resource value.

llvm-svn: 321555

It was previously set to an identifier that the user typed, leading to
surprising behavior in VSCode (probably in other editors too).

llvm-svn: 321554

As noted in PR34686, we are relying on a PSHUFD+PSHUFLW+PSHUFHW shuffle chain for most general vXi16 unary shuffles.

This patch checks for simpler PSHUFLW+PSHUFD and PSHUFHW+PSHUFD cases beforehand, building on some existing code that just handled splat shuffles.

By doing so we also prevent premature use of PSHUFB shuffles which can be slower and require the creation/loading of constant shuffle masks.

We now have the 'fast-variable-shuffle' option for hardware that prefers combining 2 or more shuffles to VPSHUFB etc.

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

llvm-svn: 321553

See bug 35730: https://bugs.llvm.org/show_bug.cgi?id=35730

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

Reviewers: vpykhtin, artem.tamazov, arsenm
llvm-svn: 321552

Revision 320791 introduced a pass that transforms reg+reg instructions to
reg+imm if they're fed by "load immediate". However, it didn't
handle out-of-range shifts correctly as reported in PR35688.
This patch fixes that and therefore the PR.

Furthermore, there was undefined behaviour in the patch where the RHS of an
initialization expression was 32 bits and constant `1` was shifted left 32
bits. This was fixed by ensuring the RHS is 64 bits just like the LHS.

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

llvm-svn: 321551

llvm-svn: 321550

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

llvm-svn: 321549

Summary:
New pass manager driver passes DebugPM (-debug-pass-manager) flag into
individual PassManager constructors in order to enable debug logging.
FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM
which never gets its debug logging enabled and that means canonicalization
passes like LoopSimplify are never present in -debug-pass-manager output.

Extending FunctionToLoopPassAdaptor's constructor and
createFunctionToLoopPassAdaptor wrapper with an optional
boolean DebugLogging argument.

Passing debug-logging flags there as appropriate.

Reviewers: chandlerc, davide

Reviewed By: davide

Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere

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

llvm-svn: 321548

Revert r321504 "[X86] Don't accidentally enable PKU on cannon lake and icelake or CLWB on cannonlake."

I based that commit on what was in Intel's public documentation here https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

Which specifically said CLWB wasn't until Icelake.

But I've since cross checked with SDE and it thinks these features exist on CNL and ICL. So now I don't know what to believe.

I've added test coverage of the current behavior as part of the revert so at least now have proof of what we're doing.

llvm-svn: 321547

Note, we don't do any bitwise manipulations when using them.

llvm-svn: 321546