4 Commits

Author	SHA1	Message	Date
Ulrich Weigand	e669c930a6	In various places throughout the code generator, there were special ... checks to avoid performing compile-time arithmetic on PPCDoubleDouble. Now that APFloat supports arithmetic on PPCDoubleDouble, those checks are no longer needed, and we can treat the type like any other. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166958 91177308-0d34-0410-b5e6-96231b3b80d8	2012-10-29 18:35:49 +00:00
Dan Gohman	fce288fc91	Eliminate more uses of llvm-as and llvm-dis. ... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81293 91177308-0d34-0410-b5e6-96231b3b80d8	2009-09-09 00:09:15 +00:00
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
Dan Gohman	034f60ed24	Generalize ExpandIntToFP to handle the case where the operand is legal ... and it's the result that requires expansion. This code is a little confusing because the TargetLoweringInfo tables for [US]INT_TO_FP use the operand type (the integer type) rather than the result type. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48206 91177308-0d34-0410-b5e6-96231b3b80d8	2008-03-11 01:59:03 +00:00