Commit Graph

8 Commits

Author SHA1 Message Date
Eric Christopher 598198edbc Revert "Temporarily Revert "Add basic loop fusion pass.""
The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358552 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-17 04:52:47 +00:00
Eric Christopher 02cc44c1b9 Temporarily Revert "Add basic loop fusion pass."
As it's causing some bot failures (and per request from kbarton).

This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358546 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-17 02:12:23 +00:00
Sanjay Patel 40bfd6fe1e [PatternMatch] Handle undef vectors consistently
This patch fixes the issue noticed in D54532. 
The problem is that cst_pred_ty-based matchers like m_Zero() currently do not match 
scalar undefs (as expected), but *do* match vector undefs. This may lead to optimization 
inconsistencies in rare cases.

There is only one existing test for which output changes, reverting the change from D53205. 
The reason here is that vector fsub undef, %x is no longer matched as an m_FNeg(). While I 
think that the new output is technically worse than the previous one, it is consistent with 
scalar, and I don't think it's really important either way (generally that undef should have 
been folded away prior to reassociation.)

I've also added another test case for this issue based on InstructionSimplify. It took some 
effort to find that one, as in most cases undef folds are either checked first -- and in the 
cases where they aren't it usually happens to not make a difference in the end. This is the 
only case I was able to come up with. Prior to this patch the test case simplified to undef 
in the scalar case, but zeroinitializer in the vector case.

Patch by: @nikic (Nikita Popov)

Differential Revision: https://reviews.llvm.org/D54631


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347318 91177308-0d34-0410-b5e6-96231b3b80d8
2018-11-20 16:08:19 +00:00
Cameron McInally 31fda7550e [FPEnv] Convert more BinaryOperator::isFNeg(...) to m_FNeg(...)
This work is to avoid regressions when we seperate FNeg from the FSub IR instruction. 

Differential Revision: https://reviews.llvm.org/D53205



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345146 91177308-0d34-0410-b5e6-96231b3b80d8
2018-10-24 14:45:18 +00:00
Sanjay Patel b70e54f12d [ConstantFold] fp_binop undef, undef --> undef
These are uncontroversial and independent of a proposed LangRef edits (D44216).

I tried to fix tests that would fold away:
rL327004
rL327028
rL327030
rL327034

I'm not sure if the Reassociate tests are meaningless yet, but they probably will be 
as we add more folds, so if anyone has suggestions or wants to fix those, please do.

Differential Revision: https://reviews.llvm.org/D44258


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327058 91177308-0d34-0410-b5e6-96231b3b80d8
2018-03-08 20:42:49 +00:00
Sanjay Patel e69c03b3a1 [Reassociate] regenerate test checks; NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317841 91177308-0d34-0410-b5e6-96231b3b80d8
2017-11-09 22:41:39 +00:00
Owen Anderson 108258ac78 Fix another infinite loop in Reassociate caused by Constant::isZero().
Not all zero vectors are ConstantDataVector's.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-20 22:34:48 +00:00
Owen Anderson 3f9c2909a5 Fix a pair of issues that caused an infinite loop in reassociate.
Terrifyingly, one of them is a mishandling of floating point vectors
in Constant::isZero().  How exactly this issue survived this long
is beyond me.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253655 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-20 08:16:13 +00:00