I believe these were added incorrectly under the belief that the load size was smaller than the input register size, but that's not true.

llvm-svn: 315795

[X86] Add an additional isel pattern to CVTDQ2PDrm/VCVTDQ2PDrm to enable load folding without the peephole pass.

This pattern is already used in AVX512VL version of these instructions. Though AVX512VL version is missing other patterns.

llvm-svn: 315794

This reverts r315697 and my ill-fated attempts to fix it on Windows.
I'll try again when I get access to a Windows machine.

llvm-svn: 315793

"No such file or directory: C:\\...\\tests\\Output\\shared-output.py.tmp/Output/Shared/SHARED.tmp"

And yet other forward-slashes don't seem to be causing the same
problem. I'll see if I can get ahold of a Windows machine to poke at
this directly later.

llvm-svn: 315792

Currently llvm assembler emits parsing error for valid IR assembly

alloca i32, i32 9, addrspace(5)
when alloca addr space is 5.

This patch fixes that.

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

llvm-svn: 315791

Summary:
This patch removes the `verifyNCD` check.

The reason for this is that the other checks are sufficient to prove or disprove correctness of any DominatorTree, and that `verifyNCD` doesn't provide (in my option) better error messages then the other ones.
Additionally, this should give a (small) improvement to the total verification time, as the check is O(n), and checking the sibling property takes O(n^3).

Reviewers: dberlin, grosser, davide, brzycki

Reviewed By: brzycki

Subscribers: llvm-commits

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

llvm-svn: 315790

There were two copies of the logic needed to construct a line stats
object for each line in a range: this patch brings it down to one. In
the future, this will make it easier for IDE clients to display coverage
in-line in source editors. To do that, we just need to move the new
LineCoverageIterator class to libCoverage.

llvm-svn: 315789

[globalisel][tablegen] Fix an unused variable warning caused by a typo (corrected OtherInsnID->OtherOpIdx).

The tests were passing by luck since the instruction ID and operand index happened to be the same.

llvm-svn: 315788

If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.

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

llvm-svn: 315787

The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.

Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:

r313096 - [ubsan] Function Sanitizer: Don't require writable text segments

Testing: check-clang, check-ubsan

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

llvm-svn: 315786

Credit to OSS-Fuzz for discovery:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3145

rdar://34526482

llvm-svn: 315785

llvm-svn: 315784

Two debugging statements snuck into the commit.

llvm-svn: 315783

I don't have access to a Windows machine at the moment, so if this
doesn't fix it I'll just revert for now.

llvm-svn: 315782

We use to resort on the generic implementation to get the mappings for
COPYs. The generic implementation resorts on table lookup and
dynamically allocated objects to get the valid mappings.

Given we already know how to map G_BITCAST and have the static mappings
for them, use that code path for COPY as well. This is much more
efficient.

Improve the compile time of RegBankSelect by up to 20%.

Note: When we eventually generate all the mappings via TableGen, we
wouldn't have to do that dance to shave compile time. The intent of this
change was to make sure that moving to static structure really pays off.

NFC.

llvm-svn: 315781

[globalisel][tablegen] Simplify named operand/operator lookups and fix a wrong-code bug this revealed.

Summary:
Operand variable lookups are now performed by the RuleMatcher rather than
searching the whole matcher hierarchy for a match. This revealed a wrong-code
bug that currently affects ARM and X86 where patterns that use a variable more
than once in the match pattern will be imported but won't check that the
operands are identical. This can cause the tablegen-erated matcher to
accept matches that should be rejected.

Depends on D36569

Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar

Subscribers: aemerson, igorb, llvm-commits, kristof.beyls

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

llvm-svn: 315780

I didn't think about '%{inputs}' having the same problem. This one
should be a fully Windows path name.

llvm-svn: 315779

llvm-svn: 315778

The test seems to trigger an android platform bug under load.

llvm-svn: 315777

llvm-svn: 315776

llvm-svn: 315775

The ParsedSourceRange class does not work correctly on Windows with the ':'
drive separators

llvm-svn: 315774

llvm-svn: 315773

It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.

Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.

llvm-svn: 315772

When LLVM_BUILD_EXTERNAL_COMPILER_RT option is set to true,
all of projects in compiler-rt are built with a freshly-built compiler using
a recursive CMake invocation.
(e.g. that's how compiler-rt is used in Swift)

Just now I have noticed that libFuzzer binaries were missing in such a case,
and ninja fuzzer returned "no such target", while ninja asan worked just fine.

To my surprise, the list of allowed targets was actually hardcoded in Clang!
While the current setup is clearly suboptimal, for the lack of a better fix
I'm just adding `fuzzer` to a list of `compiler-rt` targets.

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

llvm-svn: 315771

Lacking frame pointers, sanitized fuzzers collect bogus stack
traces and the set of stack traces grows indefinitely, leading to OOMs.

llvm-svn: 315770

Broke some builds (using libstdc++).

llvm-svn: 315769

This is particularly important for AVX512VL where we are better able to recognize the VBROADCAST loads to fold with other operations.

For AVX512VL we now use X86ISD::VBROADCAST for all of the patterns and remove the 128-bit X86ISD::VMOVDDUP.

We may be able to use this for AVX1 as well which would allow us to remove more isel patterns.

I also had to add X86ISD::VBROADCAST as a node to call combineShuffle for so that we treat it similar to X86ISD::MOVDDUP.

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

llvm-svn: 315768

[X86] Use fsub in the movddup scheduling tests to prevent a future patch from folding movddup as a broadcast load.

llvm-svn: 315767

This matches the behavior of gold and bfd. It also matches lld's own
behavior when the shared symbol is seen first

llvm-svn: 315766

llvm-svn: 315765

It could be used uninitialized since r310079.

llvm-svn: 315764

llvm-svn: 315763

llvm-svn: 315762

Summary:
There's only a tablegen testcase for IntImmLeaf and not a CodeGen one
because the relevant rules are rejected for other reasons at the moment.
On AArch64, it's because there's an SDNodeXForm attached to the operand.
On X86, it's because the rule either emits multiple instructions or has
another predicate using PatFrag which cannot easily be supported at the
same time.

Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar

Reviewed By: qcolombet

Subscribers: aemerson, javed.absar, igorb, llvm-commits, kristof.beyls

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

llvm-svn: 315761

[Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 315760

TargetRegisterInfo::getMinimalPhysRegClass is actually pretty expensive
because it has to iterate over all the register classes.
Cache this information as we need and get it so that we limit its usage.
Right now, we heavily rely on it, because this is how we get the mapping
for vregs defined by copies from physreg (i.e., the one that are ABI
related).

Improve compile time by up to 10% for that pass.

NFC

llvm-svn: 315759

NFC

llvm-svn: 315758

Match the LLVM coding standard for loop conditions.

NFC.

llvm-svn: 315757

Prior to this patch we used to create SetVectors in temporaries that
were created and destroyed for each instruction. Now, instead we create
and destroyed them only once, but clear the content for each
instruction.
This speeds up the pass by ~25%.

NFC.

llvm-svn: 315756