llvm-project.git/llvm/test/Transforms/Reassociate/fp-expr.ll, branch users/nico/python-2

[test] Use -passes in more Transforms tests

2022-10-21T15:02:02+00:00

Another step towards getting rid of dependencies to the legacy
pass manager.

Primary change here is to just do -passes=foo instead of -foo in
simple situations (when running a single transform pass). But also
updated a few test running multiple passes.

Also removed some "duplicated" RUN lines in a few tests that where
using both -foo and -passes=foo syntax. No need to do the same kind
of testing twice.

Remove BinaryOperator::CreateFNeg

2020-02-27T17:06:03+00:00

Use UnaryOperator::CreateFNeg instead.

Summary:
With the introduction of the native fneg instruction, the
fsub -0.0, %x idiom is obsolete. This patch makes LLVM
emit fneg instead of the idiom in all places.

Reviewed By: cameron.mcinally

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

Revert "Temporarily Revert "Add basic loop fusion pass.""

2019-04-17T04:52:47+00:00

The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

llvm-svn: 358552

Temporarily Revert "Add basic loop fusion pass."

2019-04-17T02:12:23+00:00

As it's causing some bot failures (and per request from kbarton).

This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda.

llvm-svn: 358546

[PatternMatch] Handle undef vectors consistently

2018-11-20T16:08:19+00:00

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

llvm-svn: 347318

[FPEnv] Convert more BinaryOperator::isFNeg(...) to m_FNeg(...)

2018-10-24T14:45:18+00:00

This work is to avoid regressions when we seperate FNeg from the FSub IR instruction. 

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

llvm-svn: 345146

[ConstantFold] fp_binop undef, undef --> undef

2018-03-08T20:42:49+00:00

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

llvm-svn: 327058

[Reassociate] regenerate test checks; NFC

2017-11-09T22:41:39+00:00

llvm-svn: 317841

Fix another infinite loop in Reassociate caused by Constant::isZero().

2015-11-20T22:34:48+00:00

Not all zero vectors are ConstantDataVector's.

llvm-svn: 253723

Fix a pair of issues that caused an infinite loop in reassociate.

2015-11-20T08:16:13+00:00

Terrifyingly, one of them is a mishandling of floating point vectors
in Constant::isZero().  How exactly this issue survived this long
is beyond me.

llvm-svn: 253655