This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure
that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on
Solaris succeed by always making the host and freshly built clang consistent.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367304

The code is now in a good enough state to pass the bunch of tests that
I have run (after fixing the bugs), so let's enable it by default.

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

llvm-svn: 367297

    
Revert the hardware loop upon finding a LoopEnd that doesn't target
the loop header, instead of asserting a failure.

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

llvm-svn: 367296

[NFC][X86][AArch64] Revisit test coverage for X s% C == 0 fold - add tests for negative divisors, INT_MIN divisors

As discussed in the review, that fold is only valid for positive
divisors, so while we can negate negative divisors,
we have to special-case INT_MIN.

llvm-svn: 367294

Summary:
Patch removes SVE and SVE2 features from ARMTargetParser as these
features are not supported on ARM.

Reviewed By: rengolin

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

llvm-svn: 367292

test-suite/MultiSource/Benchmarks/DOE-ProxyApps-C/miniGMG broke:

Only PHI nodes may reference their own value!
  %sub33 = srem i32 %sub33, %ranks_in_i

This reverts commit r367288.

llvm-svn: 367289

Summary:
While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair
is unsupported by target, nothing performs the opposite fold.
We can't do that in InstCombine or DAGCombine since neither of those has access to TTI.
So it makes most sense to teach `-div-rem-pairs` about it.

If we matched rem in expanded form, we know we will be able to place div-rem pair
next to each other so we won't regress the situation.
Also, we shouldn't decompose rem if we matched already-decomposed form.
This is surprisingly straight-forward otherwise.

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

Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner

Reviewed By: bogner

Subscribers: bogner, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367288

Summary: Equivalent to `x & -2^K`.

Reviewers: RKSimon, craig.topper

Reviewed By: RKSimon, craig.topper

Subscribers: dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 367287

This reverts r367284 (git commit b1cbe51b).
My changes to LLVMSymbolizer caused a test to fail:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/29488

llvm-svn: 367286

Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905

Reviewers: jhenderson, rupprecht, grimar

Reviewed By: jhenderson, grimar

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367284

llvm-svn: 367283

I removed all uses of AlignedCharArray since the minimum MSVC version can handle
alignas on char arrays correctly. We can therefore remove AlignedCharArray.

This patch also updates AlignedCharArrayUnion to use C++11.

llvm-svn: 367282

Looks like one of the entries isn't found on windows. I'm investigating why.
In the meantime, I'll disable this part of the test on windows.

llvm-svn: 367280

This patch adds a VFS that can be overlaid on top of another VFS
to record file system accesses using the FileCollector.
This can help to gather files that are needed for reproducers.

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

llvm-svn: 367278

As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio.

llvm-svn: 367277

Error message outputs with lowercase on Windows.
Made test work on Widnows.

For example:
llvm-lipo: error: 'i386': no such file or directory

llvm-svn: 367266

Introduce a new check to upgrade user code based on API changes in Googletest.

The check finds uses of old Googletest APIs with "case" in their name and replaces them with the new APIs named with "suite".

Patch by Alex Strelnikov (strel@google.com)
Reviewed as D62977.

llvm-svn: 367263

llvm-svn: 367259

Put the list of fixed metadata kinds in one place.

Testing: check-llvm with+without LLVM_ENABLE_MODULES=On

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

llvm-svn: 367257

llvm-svn: 367252

llvm-svn: 367251

Replaces specified architecture in universal binary input file with
slice from the file_name argument passed into the replace command.

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

llvm-svn: 367248

> llvm-svn: 366289

llvm-svn: 367245

Summary:
The script is silent for the following issue:
FileCheck %s -check-prefix=CHECK,POPCOUNT

FileCheck will catch it later, but I think we can warn here too.

Now it warns:
 ./update_llc_test_checks.py file.ll 
WARNING: Supplied prefix 'CHECK,POPCOUNT' is invalid. Prefix must contain only alphanumeric characters, hyphens and underscores. Did you mean --check-prefixes=CHECK,POPCOUNT?



Reviewers: lebedev.ri, spatel, RKSimon, craig.topper, nikic, gbedwell

Reviewed By: RKSimon

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 367244

All the clang-cmake-armv{7,8} bots are failing this test. This is an
attempt to fix this.

llvm-svn: 367243

Globals that are associated with globals with type metadata need to appear
in the merged module because they will reference the global's section directly.

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

llvm-svn: 367242

Avoids slow downs from calls to ComputeNumSignBits/computeKnownBits going too deep.

llvm-svn: 367240

Summary:
The LoadStoreOptimizer was creating instructions with 2
MachineMemOperands, which meant they were assumed to alias with all other instructions,
because MachineInstr:mayAlias() returns true when an instruction has multiple
MachineMemOperands.

This was preventing these instructions from being merged again, and was
giving the scheduler less freedom to reorder them.

Reviewers: arsenm, nhaehnle

Reviewed By: arsenm

Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367237

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

llvm-svn: 367236

llvm-svn: 367235

llvm-svn: 367233

As discussed on rL367171, we have a problem where the depth recursion used in combineX86ShufflesRecursively was subtly different to computeKnownBits etc. - it starts at Depth=1 instead of Depth=0 like the others and has a different maximum recursion depth.

This NFC patch fixes the recursion depth to start at 0, so we can more easily reuse depth values in calls from combineX86ShufflesRecursively and its helper functions in computeKnownBits etc.

llvm-svn: 367232

For llvm/test/MC/RISCV/rv64i-aliases-invalid.s, UBSan reports:

lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:371:9: runtime error:
load of value 3879186881, which is not a valid value for type
'RISCVMCExpr::VariantKind'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:371:9 in

It turns out that evaluateConstantImm does not set `VK` and it remains
unitialized when doing comparisons in `isImmXLenLI()`.

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

llvm-svn: 367230

The backend already does this via isNegatibleForFree(),
but we may want to alter the fneg IR canonicalizations
that currently exist, so we need to try harder to fold
fneg in IR to avoid regressions.

llvm-svn: 367227

Summary: As clarified in D53184, volatile load and store do not trap. Therefore, we should remove volatile checks for instructions in  `isGuaranteedToTransferExecutionToSuccessor`.

Reviewers: jdoerfert, efriedma, nikic

Reviewed By: nikic

Subscribers: hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 367226

llvm-svn: 367224

llvm-svn: 367222

llvm-svn: 367221

This is implicit in the value type checks in getSubVectorSrc - this just makes it upfront and obvious.

llvm-svn: 367220

Summary:
The existing isDivergent(Value) methods query whether a value is
divergent at its definition. However even if a value is uniform at its
definition, a use of it in another basic block can be divergent because
of divergent control flow between the def and the use.

This patch adds new isDivergent(Use) methods to DivergenceAnalysis,
LegacyDivergenceAnalysis and GPUDivergenceAnalysis.

This might allow D63953 or other similar workarounds to be removed.

Reviewers: alex-t, nhaehnle, arsenm, rtaylor, rampitec, simoll, jingyue

Reviewed By: nhaehnle

Subscribers: jfb, jvesely, wdng, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367218