This is just one place I missed swapping CMAKE_CONFIGURATION_TYPES with LLVM_ENABLE_IDE.

llvm-svn: 344568

The new name is a better fit: This class does not actually spawn any new
threads for compilation, it is just safe to call from multiple threads
concurrently.

The "Simple" part of the name did not convey much either, so it was
dropped.

llvm-svn: 344567

r344558 added an assignment to a TerminatorInst* from
BasicBlock::getTerminatorInst(), but BasicBlock::getTerminatorInst() returns an
Instruction* rather than a TerminatorInst* since r344504 so this fails to
compile.

Changing the variable to an Instruction* should get the bots building again.

llvm-svn: 344566

llvm-svn: 344565

llvm-svn: 344564

[X86] Fix a bad bitcast in the load form of vXi16 uniform shift patterns for EVEX encoded instructions.

llvm-svn: 344563

[X86] Add test cases showing failure to fold load into vpsrlw when EVEX encoded instructions are used.

There's a bad bitcast being used in the isel patterns for the vXi16 shift instructions.

llvm-svn: 344562

[X86] Disable the peephole pass on avx2-intrinsics-x86.ll and avx512bw-intrinsics.ll to ensure any load folding tests are testing isel not load folding tables.

llvm-svn: 344561

llvm-svn: 344560

llvm-svn: 344559

Make the code of blockEndsInUnreachable to match the function
blockEndsInUnreachable in CodeGen/BranchFolding.cpp. I also have
added a note to make sure the code of this function will not be
modified unless the back-end version is also modified.

An early return before outlining has been added to avoid
outlining the full function body when the first block in the
function is marked cold.

The static analysis of cold code has been amended to avoid
marking the whole function as cold by back-propagation
because the back-propagation would mark blocks with return
statements as cold.

The patch adds debug statements to help discover these problems.

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

llvm-svn: 344558

There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.

This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.

With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.

This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553.

llvm-svn: 344555

AARCH64 equivalent to D53257 - uses widening pairwise adds on vXi8 CTPOP to support i16/i32/i64 vectors.

This is a blocker for generic vector CTPOP expansion (P32655) - this will remove the aarch64 diff from D53258.

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

llvm-svn: 344554

There really aren't any generator behaviors that we need to take `CMAKE_EXTRA_GENERATOR` into account for. Where we need to take different behaviors for IDEs is mostly in enabling or disabling certain build system features that are optional but trip up the IDE UIs. Like the generation of lots of utility targets.

By changing the LLVM_ENABLE_IDE default to only being on for multi-configuration generators, we allow gating where it will impact the UI presentation, while also supporting optionally disabling the generation if your tooling workflow encounters problems. Presently being able to manually disable extra target generation is useful for Visual Studio 2017's CMake integration where the IDE has trouble displaying and working with the large number of optional targets.

llvm-svn: 344553

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

llvm-svn: 344552

llvm-svn: 344550

Variable updates within the outlined function are invisible to
debuggers. This could be improved by defining a DISubprogram for the
new function. For the moment, simply erase the debug intrinsics instead.

This fixes verifier failures about function-local metadata being used in
the wrong function, seen while testing the hot/cold splitting pass.

rdar://45142482

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

llvm-svn: 344545

Without this fix, DenseSet crashes with an assertion if constructed with an
initializer_list whose length is not a power of two.

llvm-svn: 344542

This is intended to make the backend on par with functionality that was 
added to the IR version of SimplifyDemandedVectorElts in:
rL343727
...and the original motivation is that we need to improve demanded-vector-elements 
in several ways to avoid problems that would be exposed in D51553.

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

llvm-svn: 344541

llvm-svn: 344534

The transform doesn't work if the vector constant has undef elements.

llvm-svn: 344532

Also, add tests with commuted operands. There was no coverage for that case.

llvm-svn: 344531

llvm-svn: 344528

llvm-svn: 344527

llvm-svn: 344525

This reverts r344519 due to failures in pipeline-parsing test.

llvm-svn: 344524

llvm-svn: 344523

constructor for DenseMap (DenseSet already had an initializer_list constructor).

These changes make it easier to migrate existing code that uses std::map and
std::set (which support initializer_list construction and equality comparison)
to DenseMap and DenseSet.

llvm-svn: 344522

Summary:
All the PassBuilder::parse interfaces now return descriptive StringError
instead of a plain bool. It allows to make -passes/aa-pipeline parsing
errors context-specific and thus less confusing.

TODO: ideally we should also make suggestions for misspelled pass names,
but that requires some extensions to PassBuilder.

Reviewed By: philip.pfaffe, chandlerc
Differential Revision: https://reviews.llvm.org/D53246

llvm-svn: 344519

When compiling static executable for micromips, CFI symbols
are incorrectly labeled as MICROMIPS, which cause
".eh_frame_hdr refers to overlapping FDEs." error.

This patch does not label CFI symbols as MICROMIPS, and FDEs do not
overlap anymore. This patch also exposes another bug, which is fixed
here: https://reviews.llvm.org/D52985

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

llvm-svn: 344516

This reverts r344511.

llvm-svn: 344515

As I suggested on PR39281, this patch uses PADDL pairwise addition to widen from the vXi8 CTPOP result to the target vector type.

This is a blocker for moving more x86 code to generic vector CTPOP expansion (P32655 + D53258) - ARM's vXi64 CTPOP currently expands, which would generate a vXi64 MUL but ARM's custom lowering expands the general MUL case and vectors aren't well handled in LegalizeDAG - improving the CTPOP lowering was a lot easier than fixing the MUL lowering for this one case......

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

llvm-svn: 344512

When compiling static executable for micromips, CFI symbols
are incorrectly labeled as MICROMIPS, which cause
".eh_frame_hdr refers to overlapping FDEs." error.

This patch does not label CFI symbols as MICROMIPS, and FDEs do not
overlap anymore. This patch also exposes another bug, which is fixed
here: https://reviews.llvm.org/D52985

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

llvm-svn: 344511

Change-Id: I5b64a565f22a8482aa0712488d85e45163ac3d12
llvm-svn: 344506

Removing deficiency of initial implementation of -print-before-all/-after-all
- it was effectively skipping IR printing for all the SCC passes.

Now LazyCallGraph:SCC gets its IR printed.

Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D53270

llvm-svn: 344505

This removes the primary remaining API producing `TerminatorInst` which
will reduce the rate at which code is introduced trying to use it and
generally make it much easier to remove the remaining APIs across the
codebase.

Also clean up some of the stragglers that the previous mechanical update
of variables missed.

Users of LLVM and out-of-tree code generally will need to update any
explicit variable types to handle this. Replacing `TerminatorInst` with
`Instruction` (or `auto`) almost always works. Most of these edits were
made in prior commits using the perl one-liner:
```
perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g'
```

This also my break some rare use cases where people overload for both
`Instruction` and `TerminatorInst`, but these should be easily fixed by
removing the `TerminatorInst` overload.

llvm-svn: 344504

are terminators without relying on the specific `TerminatorInst` type.

This required cleaning up two users of `InstVisitor`s usage of
`TerminatorInst` as well.

llvm-svn: 344503

by `getTerminator()` calls instead be declared as `Instruction`.

This is the biggest remaining chunk of the usage of `getTerminator()`
that insists on the narrow type and so is an easy batch of updates.
Several files saw more extensive updates where this would cascade to
requiring API updates within the file to use `Instruction` instead of
`TerminatorInst`. All of these were trivial in nature (pervasively using
`Instruction` instead just worked).

llvm-svn: 344502

This is the last interesting usage in all of LLVM's headers. The
remaining usages in headers are the core typesystem bits (Core.h,
instruction types, and InstVisitor) and as the return of
`BasicBlock::getTerminator`. The latter is the big remaining API point
that I'll remove after mass updates to user code.

llvm-svn: 344501

related code.

This is simple as we just need to replace the type and move to the
concept of visiting a "terminator" rather than a specific instruction
subclass.

llvm-svn: 344500