The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.

These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.

To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.

This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.

Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.

llvm-svn: 136023

llvm-svn: 136010

llvm-svn: 136006

This also fixes PR10452

llvm-svn: 136004

llvm-svn: 136003

shuffle before inserting on a 256-bit vector.
- Add AVX versions of movd/movq instructions
- Introduce a few COPY patterns to match insert_subvector instructions.
This turns a trivial insert_subvector instruction into a register copy,
coalescing the xmm into a ymm and avoid emiting on more instruction.

llvm-svn: 136002

native 256-bit vector instruction to do scalar_to_vector.

llvm-svn: 136001

llvm-svn: 135996

Fix the Rn register encoding for both SSAT and USAT. Update the parsing of the
shift operand to correctly handle the allowed shift types and immediate ranges
and issue meaningful diagnostics when an illegal value or shift type is
specified. Add aliases to parse an ommitted shift operand (default value of
'lsl #0').

Add tests for diagnostics and proper encoding.

llvm-svn: 135990

llvm-svn: 135986

llvm-svn: 135982

Addresses PR10466, although the crash from that PR only triggers in cases where DAGCombine misses optimizing a shuffle.

llvm-svn: 135980

llvm-svn: 135979

llvm-svn: 135978

llvm-svn: 135975

llvm-svn: 135974

The shift immediate encoding, printing, etc. is handled directly by the
enclosing operand definition, so it should be a vanilla immediate, not a
nested complex operand (shift_imm).

llvm-svn: 135968

llvm-svn: 135963

llvm-svn: 135959

llvm-svn: 135958

llvm-svn: 135954

llvm-svn: 135953

Update the comment. This feature is available only on Darwin at the moment. Though it's not Darwin-specific.

llvm-svn: 135951

llvm-svn: 135950

llvm-svn: 135949

Remove some inititalizers that are the same as the default, move defs next to
their (singular) uses and generally simplify some formatting of asm operand
definitions.

llvm-svn: 135946

llvm-svn: 135945

llvm-svn: 135943

llvm-svn: 135942

llvm-svn: 135939

llvm-svn: 135930

llvm-svn: 135924

llvm-svn: 135923

unwind encoding for that function. This simply crawls through the prolog looking
for machine instrs marked as "frame setup". It can calculate from these what the
compact unwind should look like.

This is currently disabled because of needed linker support. But initial tests
look good.

llvm-svn: 135922

llvm-svn: 135866

llvm-svn: 135837

llvm-svn: 135833

llvm-svn: 135826

llvm-svn: 135825

The immediate is in the range 1-32, but is encoded as 0-31 in a 5-bit bitfield.
Update the representation such that we store the operand as 0-31, allowing us
to remove the encoder method and the special case handling in the disassembler.
Update the assembly parser and the instruction printer accordingly.

llvm-svn: 135823