Commit Graph

4 Commits

Author SHA1 Message Date
Dan Gohman
ae3a0be92e Split the Add, Sub, and Mul instruction opcodes into separate
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.

For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.

This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-04 22:49:04 +00:00
Duncan Sands
b10b5ac8d9 Don't try to make BUILD_VECTOR operands have the same
type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it.  In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc).  This fixes a regression with the new type
legalizer (vec_splat.ll).  Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR.  After all, it is just a
special case of BUILD_VECTOR.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69467 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-18 20:16:54 +00:00
Duncan Sands
42d4499a16 Turn off LegalizeTypes for this test for the
moment, while waiting for a proper solution.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58324 91177308-0d34-0410-b5e6-96231b3b80d8
2008-10-28 09:55:04 +00:00
Chris Lattner
4af2c40c63 rename vec_spat -> vec_splat, pointed out by duncan
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58260 91177308-0d34-0410-b5e6-96231b3b80d8
2008-10-27 18:28:24 +00:00