change the set of uniform instructions in the loop causing an assert
failure.

The problem is that the legalization checking also builds data
structures mapping various facts about the loop body. The immediate
cause was the set of uniform instructions. If these then change when
LCSSA is formed, the data structures would already have been built and
become stale. The included test case triggered an assert in loop
vectorize that was reduced out of the new PM's pipeline.

The solution is to form LCSSA early enough that no information is cached
across the changes made. The only really obvious position is outside of
the main logic to vectorize the loop. This also has the advantage of
removing one case where forming LCSSA could mutate the loop but we
wouldn't track that as a "Changed" state.

If it is significantly advantageous to do some legalization checking
prior to this, we can do a more careful positioning but it seemed best
to just back off to a safe position first.

llvm-svn: 293168

Remove the reference to pthread_mach_thread_np() in libcxx headers.

llvm-svn: 293167

Pull the dependency on pthread_mach_thread_np() back into libcxxabi.

llvm-svn: 293166

In this case, we just use the start of the scop as the debug location.

llvm-svn: 293165

This patch makes one change to GOT handling and two changes to N64's
relocation model handling. Furthermore, the jumptable encodings have
been corrected for static N64.

Big GOT handling is now done via a new SDNode MipsGotHi - this node is
unconditionally lowered to an lui instruction.

The first change to N64's relocation handling is the lifting of the
restriction that N64 always uses PIC. Now it is possible to target static
environments.

The second change adds support for 64 bit symbols and enables them by
default. Previously N64 had patterns for sym32 mode only. In this mode all
symbols are assumed to have 32 bit addresses. sym32 mode support
is selectable with attribute 'sym32'. A follow on patch for clang will
add the necessary frontend parameter.

This partially resolves PR/23485.

Thanks to Brooks Davis for reporting the issue!

Reviewers: dsanders, seanbruno, zoran.jovanovic, vkalintiris

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

llvm-svn: 293164

Add support for loading i1, i8 and i16 arguments from the stack, with or without
the ABI extension flags.

When the ABI extension flags are present, we load a 4-byte value, otherwise we
preserve the size of the load and let the instruction selector replace it with a
LDRB/LDRH. This generates the same thing as DAGISel.

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

llvm-svn: 293163

it vectorizable.

llvm-svn: 293162

llvm-svn: 293161

with it.

This code was dereferencing the PoisoningVH which isn't allowed once it
is poisoned. But the code itself really doesn't need to access the
pointer, it is just doing the safe stuff of clearing out data structures
keyed on the pointer value.

Change the code to use iterators to erase directly from a DenseMap. This
is also substantially more efficient as it avoids lots of hashing and
lookups to do the erasure. DenseMap supports iterating behind the
iteration which is fairly easy to implement.

Sadly, I don't have a test case here. I'm not even close and I don't
know that I ever will be. The issue is that several of the tricky
aspects of fixing this only show up when you cause the stack's
SmallVector to be in *EXACTLY* the right location. I only ever got
a reproduction for those with Clang, and only with *exactly* the right
command line flags. Any adjustment, even to seemingly unrelated flags,
would make partial and half-way solutions magically start to "work". In
good news, all of this was caught with the LLVM test suite. Also, there
is no *specific* code here that is untested, just that the old pattern
of code won't immediately fail on any test case I've managed to
contrive.

llvm-svn: 293160

"this", aka class members, is not referred in the body.

llvm-svn: 293159

llvm-svn: 293158

[AVX-512] Move the combine that runs combineBitcastForMaskedOp to the last DAG combine phase where I had originally meant to put it.

llvm-svn: 293157

[X86] When bitcasting INSERT_SUBVECTOR/EXTRACT_SUBVECTOR to match masked operations, use the correct type for the immediate operand.

llvm-svn: 293156

Refactoring to remove duplications of this method.

New method getOperandsScalarizationOverhead() that looks at the present unique
operands and add extract costs for them. Old behaviour was to just add extract
costs for one operand of the type always, which still happens in
getArithmeticInstrCost() if no operands are provided by the caller.

This is a good start of improving on this, but there are more places
that can be improved by using getOperandsScalarizationOverhead().

Review: Hal Finkel
https://reviews.llvm.org/D29017

llvm-svn: 293155

Use the new __has_feature(cxx_constexpr_string_builtins) for detection of the C-string intrinsics for constexpr support in std::char_traits. Thanks to Richard for the intrisic support.

llvm-svn: 293154

llvm-svn: 293153

llvm-svn: 293152

This intrinsic uses bit 0 and bit 4 of an immediate argument to determine which bits of its inputs to read. This patch uses this information to simplify the demanded elements of the input vectors.

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

llvm-svn: 293151

llvm-svn: 293150

Require aarch64 and avoid filename in YAML since it may require quotation.

llvm-svn: 293149

llvm-svn: 293148

llvm-svn: 293147

The handler that deals with IR passed/missed/analysis remarks is extended to
also handle the corresponding MIR remarks.

The more thorough testing in done via llc (rL293113, rL293121).  Here we just
make sure that the functionality is accessible through clang.

llvm-svn: 293146

It will be used from clang.

llvm-svn: 293145

llvm-svn: 293144

Negative flags are still bit flags, so I think "not flag" is a very good name.

llvm-svn: 293143

llvm-svn: 293142

llvm-svn: 293141

debugserver-mini can use Foundation.

llvm-svn: 293140

Patch by Dmitry Mikulin.
PR: 31735

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

llvm-svn: 293139

Now we never append a number to the file name for task ID 0.

This is similar to r293132 in the gold plugin.

llvm-svn: 293138

llvm-svn: 293137

factory functions for the two modes the loop unroller is actually used
in in-tree: simplified full-unrolling and the entire thing including
partial unrolling.

I've also wired these up to nice names so you can express both of these
being in a pipeline easily. This is a precursor to actually enabling
these parts of the O2 pipeline.

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

llvm-svn: 293136

requires that this private framework be available - and it is not
available earlier than macOS 10.12 - to build lldb), dlopen the
framework binary on demand in debugserver.  We're already using
dlsym() to look up all the symbols so there is no need to use weak
linking here.

<rdar://problem/30158797> 

llvm-svn: 293135

Instead of using the location of the beginning '-'/'+'.
This is consistent with location used for function decls and ObjC method calls where we use the base name as the location as well.

llvm-svn: 293134

directly walks the current loop structure verifying that a matching
structure can be found in a freshly computed version.

Also pull things out of containers when necessary once an issue is found
and print them directly.

This makes it substantially easier to debug verification failures as
the process stops at the exact point in the loop nest where they diverge
and has in easily accessed local variables (or printed to stderr
already) the loops and other information needed to analyze the failure.

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

llvm-svn: 293133

Now we never append a number to the file name for task ID 0.

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

llvm-svn: 293132

llvm-svn: 293131

llvm-svn: 293130

llvm-svn: 293129