as the operator of the dag. Specifically, this allows parsing things
like (F.x 4) in addition to just (a 4).
Unfortunately, this runs afoul of an idiom being used by llvmc. It
is using dags like (foo [1,2,3]) to represent a list of stuff being
passed into foo. With this change, this is parsed as a [1,2,3]
subscript on foo instead of being the first argument to the dag.
Cope with this in the short term by requiring a "-llvmc-temp-hack"
argument to tblgen to get the old parsing behavior.
llvm-svn: 115742
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics.
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces. Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
llvm-svn: 115243
or not. TableGen needs to generate the printInstruction() function as taking
an MCInstr* or a MachineInstr*, depending. Default to the old non-MC
version so that everything not yet using MC continues to just work without
fidding.
llvm-svn: 115126
shell runner.
We would inadvertently end up holding on to handles to the temporary files
longer than we should have been. On Win32, where open handles lock some file
operations, this caused problems in tests which would try to move temporary
files around (as Clang does by default now).
Many thanks to Francois Pichet for the excellent detective work on this.
llvm-svn: 115040
operands.
With this done, we can remove the _Int suffixes from the round instructions
without the disassembler blowing up. This allows the assembler to support
them, implementing rdar://8456376 - llvm-mc rejects 'roundss'
llvm-svn: 115019
available targets unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies
LLVM_INCLUDE_X"
It breaks the configuration phase when cmake is invoked without
parameters, it is too complex for the purpose and introduces an
incovenience for the user (as both LLVM_BUILD_X and LLVM_INCLUDE_X
must set to OFF for not including X on the build)
llvm-svn: 114795
