There is a conflict between libomptarget and libomp concerning some of the
standard OpenMP device API which needs further intestigation.

llvm-svn: 347932

First part of P0482 - Establish that char8_t is an integral type, and that numeric_limits<char8_t> is valid and sane. (second try)

llvm-svn: 347930

llvm-svn: 347929

Also add a shebang line to write_cmake_config.py.

llvm-svn: 347928

Also adds a boring build file for llvm/lib/BinaryFormat (needed by llvm/lib/IR).

lib/IR marks Attributes and IntrinsicsEnum as public_deps (because IR's public
headers include the generated .inc files), so projects depending on lib/IR will
implicitly depend on them being generated. As a consequence, most targets won't
have to explicitly list a dependency on these tablegen steps (contrast with
intrinsics_gen in the cmake build).

This doesn't yet have the optimization where tablegen's output is only updated
if it's changed.

Differential Revision: https://reviews.llvm.org/D55028#inline-486755

llvm-svn: 347927

This patch passes -fdebug-prefix-map (a feature for renaming source
paths in the debug info) through to the per-module codegen options and
adds the debug prefix map to the module hash.

<rdar://problem/46045865>

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

llvm-svn: 347926

Also fix a missing file in lib/Support/BUILD.gn found by the script.

The script is very stupid and assumes that CMakeLists.txt follow the standard
LLVM CMakeLists.txt formatting with one cpp source file per line. Despite its
simplicity, it works well in practice.

It would be nice if it also checked deps and maybe automatically applied its
suggestions.

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

llvm-svn: 347925

Earlier this month there was a change in clang that defaulted to using codeview rather than dwarf on Windows. Since all the tests rely on dwarf, we need to explicitly request dwarf when building on Windows.

llvm-svn: 347924

Summary:
Expands for vector types all of the integer operations that are
expanded for scalars because they are not supported at all by
WebAssembly.

This CL has no tests because such tests would really be testing the
target-independent expansion, but I'm happy to add tests if reviewers
think it would be helpful.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 347923

Scattered ARM relocations for Mach-O's only have 24 bits available to
encode the offset. This is not checked but just truncated and can result
in corrupt binaries after linking because the relocations are applied to
the wrong offset. This patch will check and error out in those
situations instead of emitting a wrong relocation.

Patch by: Sander Bogaert (dzn)

Differential revision: https://reviews.llvm.org/D54776

llvm-svn: 347922

The test was previously marked as unsupported on all Apple platforms, when
we really just want to mark it as unsupported for previously shipped dylibs
on macosx.

llvm-svn: 347920

initialization.

Function __kmpc_global_thread_num  should be called only after
initialization, not earlier.

llvm-svn: 347919

I forgot to do this before committing D54755.

llvm-svn: 347918

The motivating case for this is shown in:
https://bugs.llvm.org/show_bug.cgi?id=32023
and the corresponding rot16.ll regression tests.

Because x86 scalar shift amounts are i8 values, we can end up with trunc-binop-trunc 
sequences that don't get folded in IR.

As the TODO comments suggest, there will be regressions if we extend this (for x86, 
we mostly seem to be missing LEA opportunities, but there are likely vector folds 
missing too). I think those should be considered existing bugs because this is the 
same transform that we do as an IR canonicalization in instcombine. We just need 
more tests to make those visible independent of this patch.

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

llvm-svn: 347917

yaml2obj writes the yaml value as is to the output file.

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

llvm-svn: 347916

Summary: This patch adds a new runtime for the SPMD deinit kernel function which replaces the previous function. The new function takes as argument the flag which signals whether the runtime is required or not. This enables the compiler to optimize out the part of the deinit function which are not needed.

Reviewers: ABataev, caomhin

Reviewed By: ABataev

Subscribers: jholewinski, guansong, cfe-commits

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

llvm-svn: 347915

Utilise a similar ('late') lowering strategy to D47882. The changes to 
AtomicExpandPass allow this strategy to be utilised by other targets which 
implement shouldExpandAtomicCmpXchgInIR.

All cmpxchg are lowered as 'strong' currently and failure ordering is ignored. 
This is conservative but correct.

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

llvm-svn: 347914

Adding .vscode to svn:ignore

llvm-svn: 347913

[X86] Change the pre-type legalization DAG combine added in r347898 into a custom type legalization operation instead.

This seems to produce the same results on the tests we have.

llvm-svn: 347912

Also revert fix r347876

One of the buildbots was reporting a failure in some relevant tests that I can't
repro or explain at present, so reverting until I can isolate.

llvm-svn: 347911

Currently CaptureTracker gives up if it encounters a value with more than 20 
uses. The motivation for this cap is to keep it relatively cheap for 
BasicAliasAnalysis use case, where the results can't be cached. Although, other 
clients of CaptureTracker might be ok with higher cost. This patch introduces an 
argument for PointerMayBeCaptured functions to specify the max number of uses to 
explore. The motivation for this change is a downstream user of CaptureTracker, 
but I believe upstream clients of CaptureTracker might also benefit from more 
fine grained cap.

Reviewed By: hfinkel

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

llvm-svn: 347910

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

llvm-svn: 347909

llvm-svn: 347908

This patch adds __kmpc_omp_reg_task_with_affinity to register affinity
information for tasks. For now, the affinity information is not used,
and the function always succeeds. This also adds the kmp_task_affinity_info_t
structure to store the task affinity information.

Patch by Terry Wilmarth

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

llvm-svn: 347907

It makes more sense to order FI-based memops in descending order when
the stack goes down. This allows offsets to stay "consecutive" and allow
easier pattern matching.

llvm-svn: 347906

This reverts commit 0859c80137ac5fb3c86e7802cb8c5ef56f921cce.

llvm-svn: 347905

First part of P0482 - Establish that char8_t is an integral type, and that numeric_limits<char8_t> is valid and sane.

llvm-svn: 347904

Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.

Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF

Subscribers: christof, jkorous, libcxx-commits

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

llvm-svn: 347903

[SelectionDAG][AArch64][X86] Move legalization of vector MULHS/MULHU from LegalizeDAG to LegalizeVectorOps

I believe we should be legalizing these with the rest of vector binary operations. If any custom lowering is required for these nodes, this will give the DAG combine between LegalizeVectorOps and LegalizeDAG to run on the custom code before constant build_vectors are lowered in LegalizeDAG.

I've moved MULHU/MULHS handling in AArch64 from Lowering to isel. Moving the lowering earlier caused build_vector+extract_subvector simplifications to kick in which made the generated code worse.

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

llvm-svn: 347902

This difference is very visible because it is used with other Visitor
classes together.

llvm-svn: 347901

llvm-svn: 347900

llvm-svn: 347899

[X86] Add a DAG combine pre type legalization to widen division by constant splat on narrow vectors to avoid scalarization

This is another patch for -x86-experimental-vector-widening. This pre widens narrow division by constants so that we can get pass the legal type check in the generic DAG combiner. Otherwise we end up scalarizing.

I've restricted this to splats for now because it was easy to just call DAG.getConstant. Not sure what we should do for non-splat? Increase the element size?Widen the constant vector by padding with 1?

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

llvm-svn: 347898

Summary:
This patch passes an option '-z max-page-size=4096' to lld through clang driver.

This is for Android on Aarch64 target.

The lld default page size is too large for Aarch64, which produces larger .so files and images for arm64 device targets.
In this patch we set default page size to 4KB for Android Aarch64 targets instead.

Reviewers: srhines, danalbert, ruiu, chh, peter.smith

Reviewed By: srhines

Subscribers: javed.absar, kristof.beyls, cfe-commits, george.burgess.iv, llozano

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

llvm-svn: 347897

This is an almost direct move of the functionality from InstCombine to 
InstSimplify. There's no reason not to do this in InstSimplify because 
we never create a new value with this transform.

(There's a question of whether any dominance-based transform belongs in
either of these passes, but that's a separate issue.)

I've changed 1 of the conditions for the fold (1 of the blocks for the 
branch must be the block we started with) into an assert because I'm not 
sure how that could ever be false.

We need 1 extra check to make sure that the instruction itself is in a
basic block because passes other than InstCombine may be using InstSimplify
as an analysis on values that are not wired up yet.

The 3-way compare changes show that InstCombine has some kind of 
phase-ordering hole. Otherwise, we would have already gotten the intended
final result that we now show here.

llvm-svn: 347896

Reviewers: rsmith, void, shafik

Reviewed By: void

Subscribers: kristina, cfe-commits

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

llvm-svn: 347895

When tablegen detects that there exist two subregister compositions that
result in the same value for some register, it will emit a warning. This
kind of an overlap in compositions should only happen when it is caused
by a user-defined composition. It can happen, however, that the user-
defined composition is not identically equal to another one, but it does
produce the same value for one or more registers. In such cases suppress
the warning.
This patch is to silence the warning when building the System Z backend
after D50725.

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

llvm-svn: 347894

Summary:
Replace `aext([asz]ext x)` with `aext/sext/zext x` in order to
reduce the number of instructions generated to clean up some
legalization artifacts.

Reviewers: aditya_nandakumar, dsanders, aemerson, bogner

Reviewed By: aemerson

Subscribers: rovka, kristof.beyls, javed.absar, llvm-commits

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

llvm-svn: 347893

Test added in r347887 requires an x86 target.

llvm-svn: 347892

Summary: The original intention of !Config.xx.empty() was probably to emphasize the thing that is currently considered, but I feel the simplified form is actually easier to understand and it is also consistent with the call sites in other llvm components.

Reviewers: alexshap, rupprecht, jakehehrlich, jhenderson, espindola

Reviewed By: alexshap, rupprecht

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 347891