Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Revert "Temporarily Revert "Add basic loop fusion pass."" | Eric Christopher | 2019-04-17 | 1 | -0/+52 |
| | | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552 | ||||
* | Temporarily Revert "Add basic loop fusion pass." | Eric Christopher | 2019-04-17 | 1 | -52/+0 |
| | | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546 | ||||
* | [ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmps | Hal Finkel | 2016-05-04 | 1 | -0/+52 |
ConstantFold has logic to take icmp (bitcast x to y), null and strip the bitcast. This makes sense in general, but not if x has floating-point type. In this case, we'd need a fcmp, not an icmp, and the code will assert. We normally don't see this situation because we constant fold fp -> int bitcasts, however, we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is Endian-dependent, and as a result, we don't simplify it in ConstantFold (we could, but no one has yet added the necessary logic). Regardless, ConstantFold should not depend on that canonicalization for correctness. llvm-svn: 268534 |