llvm-svn: 364175

We accidentally lost the ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT macros
in r363794.

Also put the `memory_order` typedef back inside a `>= CL2.0` guard.

llvm-svn: 364174

Identified the duplicate declarations using

  sort lib/Headers/opencl-c.h | uniq -c | grep '      2'

llvm-svn: 364173

This adds the family of loads and stores with names like VLD20.8 and
VST42.32, which load and store parts of multiple q-registers in such a
way that executing both VLD20 and VLD21, or all four of VLD40..VLD43,
will distribute 2 or 4 vectors' worth of memory data across the lanes
of the same number of registers but in a transposed order.

In addition to the Tablegen descriptions of the instructions
themselves, this patch also adds encode and decode support for the
QQPR and QQQQPR register classes (representing the range of loaded or
stored vector registers), and tweaks to the parsing system for lists
of vector registers to make it return the right format in this case
(since, unlike NEON, MVE regards q-registers as primitive, and not
just an alias for two d-registers).

llvm-svn: 364172

The existing symbol code documentation was very incomplete. This patch
adds the missing codes, and defines them based on the current code
behaviour.

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

Reviewed by: rupprecht, mtrent, MaskRay

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

llvm-svn: 364171

Use binary mode to read test files in libcxx LibcxxTestFormat class.
This ensures that tests are read correctly independently of encoding,
and therefore fixes UnicodeDecodeError when file is opened in Python 3
that defaults to pure ASCII encoding.

Technically this could be also fixed via conditionally appending
encoding argument when opening the file in Python 3.  However, since
the code in question only searches for fixed ASCII substrings reading
it in binary mode is simpler and more universal.

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

llvm-svn: 364170

Summary:
These functions are documented as not modifying the offset argument if
the extraction fails (just like other DataExtractor functions). However,
while reviewing D63591 we discovered that this is not the case -- if the
function reaches the end of the data buffer, it will just return the
value parsed until that point and set offset to point to the end of the
buffer.

This fixes the functions to act as advertised, and adds a regression
test.

Reviewers: dblaikie, probinson, bkramer

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 364169

Minor reshuffle in AArch64 targetparser unittest, solving a potential problem
with querying iterators too early.

llvm-svn: 364168

We do not need the elf-groups.x86_64. In one of the tests, it was
used for no solid reason, and for the second test case we can use
YAML input with SHT_GROUP sections.

The patch performs a cleanup of one of the test cases, removes another
one completely (since during the review was found out it actually
duplicates one of the existent tests) and removes the precompiled binary.

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

llvm-svn: 364167

type-dependent argument packs.

We need to strip off the PackExpansionExpr to get the real (dependent)
type rather than an opaque DependentTy.

llvm-svn: 364165

[ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}

Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.

The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.

The upper bound of the error message is not correct. Fix it as well.

The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.

Reviewed By: ruiu

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

llvm-svn: 364164

[X86] Turn v16i16->v16i8 truncate+store into a any_extend+truncstore if we avx512f, but not avx512bw.

Ideally we'd be able to represent this truncate as a any_extend to
v16i32 and a truncate, but SelectionDAG doens't know how to not
fold those together.

We have isel patterns to use a vpmovzxwd+vpdmovdb for the truncate,
but we aren't able to simultaneously fold the load and the store
from the isel pattern. By pulling the truncate into the store we
can successfully hide it from the DAG combiner. Then we can isel
pattern match the truncstore and load+any_extend separately.

llvm-svn: 364163

When I executed gn.py gen out/gn I got the following error:

ERROR at //compiler-rt/lib/builtins/BUILD.gn:162:7: Only source, header, and object files belong in the sources of a static_library. //compiler-rt/lib/builtins/emutls.c  is not one of the valid types.
      "emutls.c ",
      ^----------
See //compiler-rt/lib/BUILD.gn:3:5: which caused the file to be included.
    "//compiler-rt/lib/builtins",
    ^---------------------------
It turns out to be that the latest gn doesn't accept ill-format file name. And the emutls.c above has a trailing space.
Remove the trailing space should work.

Patch By: myhsu
Differential Revision: https://reviews.llvm.org/D63449

llvm-svn: 364162

llvm-svn: 364161

The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.

llvm-svn: 364160

llvm-svn: 364159

[X86] Fix isel pattern that was looking for a bitcasted load. Remove what appears to be a copy/paste mistake.

DAG combine should ensure bitcasts of loads don't exist.

Also remove 3 patterns that are identical to the block above them.

llvm-svn: 364158

llvm-svn: 364157

llvm-svn: 364156

In rL364135, I taught IndVars to fold exiting branches in loops with a zero backedge taken count (i.e. loops that only run one iteration).  This extends that to eliminate the dead comparison left around.  

llvm-svn: 364155

llvm-svn: 364154

This is another intermediate IR step towards solving PR42314:
https://bugs.llvm.org/show_bug.cgi?id=42314

We can test if a value is power-of-2-or-0 using ctpop(X) < 2,
so combining that with a non-zero check of the input is the
same as testing if exactly 1 bit is set:

(X != 0) && (ctpop(X) u< 2) --> ctpop(X) == 1

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

llvm-svn: 364153

llvm-svn: 364152

[SelectionDAG] Remove the code that attempts to calculate the alignment for the second half of a split masked load/store.

The code divides the alignment by 2 if the original alignment is
equal to the original VT size. But this wouldn't be correct
if the alignment was larger than the VT size.

The memory operand object already takes care of calling MinAlign
on the base alignment and the memory pointer offset. So we don't
need any special code at all.

llvm-svn: 364151

[X86][SelectionDAG] Cleanup and simplify masked_load/masked_store in tablegen. Use more precise PatFrags for scalar masked load/store.

Rename masked_load/masked_store to masked_ld/masked_st to discourage
their direct use. We need to check truncating/extending and
compressing/expanding before using them. This revealed that
our scalar masked load/store patterns were misusing these.

With those out of the way, renamed masked_load_unaligned and
masked_store_unaligned to remove the "_unaligned". We didn't
check the alignment anyway so the name was somewhat misleading.

Make the aligned versions inherit from masked_load/store instead
from a separate identical version. Merge the 3 different alignments
PatFrags into a single version that uses the VT from the SDNode to
determine the size that the alignment needs to match.

llvm-svn: 364150

llvm-svn: 364149

Clang provides __is_same that doesn't produce any instantiations
and just returns a bool. It's a lot faster than using std::is_same

I'll follow up with a patch to actually start using it.

llvm-svn: 364148

This reverts commit SVN r364137.  This seems to be cause problems with
casting in C.

llvm-svn: 364147

The CMake CheckLibcxxAtomic module was always failing to compile
the example, even when libatomic wasn't needed. This was caused
because the check doesn't link a C++ runtime library to provide
std::terminate, which is required for exception support.

The check is still really broken, but <atomic> is better!

llvm-svn: 364146

For example, the following TypeAliasTemplateDecl now displays in the autos window as
template<class T> using type_identity_t = type_identity<T>::type;

llvm-svn: 364145

llvm-svn: 364144

Summary:
Emscripten's libc doesn't define MNT_LOCAL, thus causing a build
failure in the fallback path. However, to the best of my knowledge,
it also doesn't support remote file system mounts, so we may simply
return `true` here (as we do for e.g. Fuchsia). With this fix, the
core LLVM libraries build correctly under emscripten (though some
of the tools and utils do not).

Reviewers: kripken
Differential Revision: https://reviews.llvm.org/D63688

llvm-svn: 364143

llvm-svn: 364142

This reverts r364134 (git commit a5b83bc9)

Caused errors in the asan bot, so the GeneralCategory global needs to
be changed to ManagedStatic.

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

llvm-svn: 364141

Unnamed bit-fields should not be represented in the TBAA metadata
because they do not represent storage fields (they only affect layout).

Zero-sized fields should not be represented in the TBAA metadata
because by definition they have no associated storage (so we will never
emit a load or store through them), and they might not appear in
declaration order within the struct layout.

Fixes a verifier failure when emitting a TBAA-enabled load through a
class type containing a zero-sized field.

llvm-svn: 364140

llvm-svn: 364139

E.g., Allow MSVC to visualize a CXXConstructorDecl like 
Constructor { Y(type_identity_t<T>)}

llvm-svn: 364138

This is reduced from MSVC's MSVCPRT 14.21.27702 atomic header.  Because
Windows is a LLP64 environment, `long`, `long int`, and `int` are all
synonymous.  Change the signature for `__iso_volatile_load32` and
`__iso_volatile_store32` to accept a `long int` instead.  This allows
an implicit cast of `int` to `long int` while also permitting `long`
to be accepted.

llvm-svn: 364137

[X86][SSE] Fold extract_subvector(vselect(x,y,z),0) -> vselect(extract_subvector(x,0),extract_subvector(y,0),extract_subvector(z,0))

llvm-svn: 364136

This turned out to be surprisingly effective. I was originally doing this just for completeness sake, but it seems like there are a lot of cases where SCEV's exit count reasoning is stronger than it's isKnownPredicate reasoning.

Once this is in, I'm thinking about trying to build on the same infrastructure to eliminate provably untaken checks. There may be something generally interesting here.

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

llvm-svn: 364135