| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | In various places throughout the code generator, there were special | Ulrich Weigand | 2012-10-29 | 1 | -1/+2 |
| | | | | | | | | | | 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. llvm-svn: 166958 | ||||
| * | Eliminate more uses of llvm-as and llvm-dis. | Dan Gohman | 2009-09-09 | 1 | -1/+1 |
| | | | | | llvm-svn: 81293 | ||||
| * | Split the Add, Sub, and Mul instruction opcodes into separate | Dan Gohman | 2009-06-04 | 1 | -1/+1 |
| | | | | | | | | | | | | | | | | 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 llvm-svn: 72897 | ||||
| * | Generalize ExpandIntToFP to handle the case where the operand is legal | Dan Gohman | 2008-03-11 | 1 | -0/+11 |
| 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. llvm-svn: 48206 | |||||
 |
index : bcm5719-llvm | |
| Project Ortega BCM5719 LLVM | Raptor Computing Systems |
| summaryrefslogtreecommitdiffstats |
|