[PATCH] D61604: [InstCombine] sink FP negation of operands through select

[Kevin Neal via llvm-commits]

It might be a useful experiment (changing FSub to emit an FNeg as appropriate) at least to see how many tests fail and how they fail. It looks like a ton of tests use fsub -0.0.

--
Kevin P. Neal
SAS/C and SAS/C++ Compiler
Host Research and Development
SAS Institute, Inc.



From: Cameron McInally <cameron.mcinally at nyu.edu>
Sent: Tuesday, May 07, 2019 2:20 PM
To: Sanjay Patel <spatel at rotateright.com>
Cc: Kevin Neal <Kevin.Neal at sas.com>; Matthew.Arsenault at amd.com; andrew.kaylor at intel.com; mcrosier at codeaurora.org; wei.ding2 at amd.com; hiraditya at msn.com; llvm-commits at lists.llvm.org; jun.l at samsung.com
Subject: Re: [PATCH] D61604: [InstCombine] sink FP negation of operands through select


EXTERNAL
On Tue, May 7, 2019 at 11:44 AM Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote:

On Tue, May 7, 2019 at 7:16 AM Kevin Neal <Kevin.Neal at sas.com<mailto:Kevin.Neal at sas.com>> wrote:

How should we handle regressions in code quality that are exposed by tests?

One idea I had (or I may be remembering someone else's suggestion) was to grep the existing IR regression tests for 'fsub -0.0', then create a sibling test using fneg. If that doesn't result in the same output, then we need to do some pattern matching enhancement.

I'm not opposed to this, but it does sound like a ton of work.

What if we checked for a -0.0 constant in IRBuilder::FSub*(...) and created an FNeg instead? Then we should only see test changes with `fsub -0.0`-> `fneg`. If we find anything else, it would need a closer look. Does that miss anything?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190507/4b96b091/attachment.html>