llvm-svn: 136109

llvm-svn: 136108

llvm-svn: 136065

llvm-svn: 136051

support for 256-bit versions (but no instruction selection yet, coming next).

llvm-svn: 136050

llvm-svn: 136049

llvm-svn: 136048

27 insertions(+), 62 deletions(-)

llvm-svn: 136047

llvm-svn: 136031

Rename TargetAsmParser to MCTargetAsmParser and TargetAsmLexer to MCTargetAsmLexer; rename createAsmLexer to createMCAsmLexer and createAsmParser to createMCAsmParser.

llvm-svn: 136027

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

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

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

llvm-svn: 135980

llvm-svn: 135974

llvm-svn: 135963

llvm-svn: 135954

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

llvm-svn: 135951

llvm-svn: 135949

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: 135833

llvm-svn: 135826

InitializeX86MCInstrInfo, etc. are combined into InitializeX86TargetMC.

llvm-svn: 135812

load folding logic

llvm-svn: 135801

llvm-svn: 135794

too. Patch by Jeff Muizelaar.

llvm-svn: 135789

of doing the RAUW calls for the overflow value itself. This makes
it more consistent with how the rest of LegalizeDAG works.

llvm-svn: 135788

Remove the escaped newline.

llvm-svn: 135739

the way to go. Doing this here will prevent several node matches later,
and would have to force looking all the way through several
VINSERTF128/VEXTRACTF128 chains to optimize simple things.

llvm-svn: 135730

and was actually very wrong, fix it and make it simpler. Also remove the
ConcatVectors function, which is unused now.

- Fix a introduction of useless nodes in r126664 and r126264. The
VUNPCKL* should never be introduced cause we don't want duplicate
nodes for 128 AVX and non-AVX modes, the actual instruction
difference only exists during isel, but not for target specific DAG
nodes. We only introduce V* target nodes when there is no 128-bit
version already there.

- Fix a fragile test and make it more useful.

llvm-svn: 135729

vxorps + vinsertf128 pair of instructions

llvm-svn: 135727

direclty supported and should be promoted and handled by smaller
shuffles

llvm-svn: 135726