Page MenuHomePhabricator

cameron.mcinally (Cameron McInally)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 6 2015, 6:21 AM (241 w, 4 d)

Recent Activity

Yesterday

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Given that we may still want the binary fneg generated in Reassociate.cpp, this may be enough then, plus what was done in D66612.

Fri, Aug 23, 1:50 PM · Restricted Project
cameron.mcinally committed rG688f3bc240d0: [Reassoc] Small fix to support unary FNeg in NegateValue(...) (authored by cameron.mcinally).
[Reassoc] Small fix to support unary FNeg in NegateValue(...)
Fri, Aug 23, 8:52 AM

Thu, Aug 22

cameron.mcinally added a comment to D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).

BTW, general comment: Many of the remaining BinaryOperator contexts in Reassociate.cpp will need re-examaination too as UnaryOperator may also be present in places where it currently is not.

Thu, Aug 22, 1:29 PM · Restricted Project
cameron.mcinally added inline comments to D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).
Thu, Aug 22, 1:25 PM · Restricted Project
cameron.mcinally created D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).
Thu, Aug 22, 11:49 AM · Restricted Project

Tue, Aug 20

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

@mcberg2017 Do you have a test you can share?

Tue, Aug 20, 7:00 AM · Restricted Project

Wed, Aug 14

cameron.mcinally updated the diff for D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Updated patch to generate unary FNeg in Clang.

Wed, Aug 14, 3:08 PM · Restricted Project

Fri, Aug 9

cameron.mcinally accepted D66016: [DAGCombiner] exclude x*2.0 from normal negation profitability rules.

LGTM. Less invasive is good.

Fri, Aug 9, 11:26 AM · Restricted Project

Thu, Aug 8

cameron.mcinally committed rG8416f20f2f55: [LICM] Support unary FNeg in LICM (authored by cameron.mcinally).
[LICM] Support unary FNeg in LICM
Thu, Aug 8, 2:39 PM

Wed, Aug 7

cameron.mcinally edited reviewers for D65908: Support unary FNeg in LICM, added: craig.topper; removed: craig.scott.
Wed, Aug 7, 2:39 PM · Restricted Project
cameron.mcinally created D65908: Support unary FNeg in LICM.
Wed, Aug 7, 2:38 PM · Restricted Project
cameron.mcinally committed rG0091621e0c45: [NFC][LICM] Pre-commit test for unary FNeg support in LICM. (authored by cameron.mcinally).
[NFC][LICM] Pre-commit test for unary FNeg support in LICM.
Wed, Aug 7, 2:30 PM
cameron.mcinally committed rG303b6dbfb47c: [EarlyCSE] Add support for unary FNeg to EarlyCSE (authored by cameron.mcinally).
[EarlyCSE] Add support for unary FNeg to EarlyCSE
Wed, Aug 7, 7:35 AM

Tue, Aug 6

cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Updated patch for Joe's suggestion.

Tue, Aug 6, 4:15 PM · Restricted Project
cameron.mcinally planned changes to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.
Tue, Aug 6, 11:06 AM · Restricted Project
cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Correct hash_combine(...) use.

Tue, Aug 6, 10:18 AM · Restricted Project
cameron.mcinally planned changes to D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Ah, I misunderstood hash_combine(...). This patch needs work...

Tue, Aug 6, 10:07 AM · Restricted Project
cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Remove unnecessary {}'s.

Tue, Aug 6, 10:02 AM · Restricted Project
cameron.mcinally created D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.
Tue, Aug 6, 10:01 AM · Restricted Project
cameron.mcinally committed rG9c52f66f4822: [NFC][EarlyCSE] Pre-commit unary FNeg tests. (authored by cameron.mcinally).
[NFC][EarlyCSE] Pre-commit unary FNeg tests.
Tue, Aug 6, 9:42 AM

Thu, Aug 1

cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Thu, Aug 1, 12:06 PM · Restricted Project
cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Thu, Aug 1, 12:00 PM · Restricted Project
cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Thu, Aug 1, 9:07 AM · Restricted Project

Wed, Jul 31

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Kind of a larger question: Do we want to include the VisitUnaryMinus change into one mega-Diff? Or should we have several separate Diffs for each of the individual CreateFNeg(...) changes?

Wed, Jul 31, 5:19 PM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Thanks for pointing this out, Craig. I do see VisitUnaryMinus(...) now. [I'm glad that Clang distinguished between the unary and binary fneg -- that could've been trouble. ;)]

Wed, Jul 31, 1:41 PM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Sorry I wasn't very clear there. There are certainly places that use it, but the code for unary minus operator does not use CreateFNEG. it asks for the constant value to use for negation and the makes an fsub or sub depending on fp or int.

Wed, Jul 31, 10:40 AM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Clang does not use the IRBuilder fneg entry point. When do we plan to switch clang over?

Wed, Jul 31, 9:23 AM · Restricted Project

Tue, Jul 30

Herald added a reviewer for D61437: [AArch64] Static (de)allocation of SVE stack objects.: rengolin.
Tue, Jul 30, 1:35 PM

Mon, Jul 29

cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.

How about we add a TODO comment regarding Cameron's topic? Would that be sufficient?

Mon, Jul 29, 11:59 AM · Restricted Project
cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.

Saw that this was Accepted while I was writing my last comment...

Mon, Jul 29, 11:45 AM · Restricted Project
cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.
  1. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because:

    "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result."

    In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?)
Mon, Jul 29, 11:37 AM · Restricted Project
cameron.mcinally committed rGb32a6592ebc4: [NFC][FPEnv] Pre-commit tests for canonicalize negated operand of fdiv. (authored by cameron.mcinally).
[NFC][FPEnv] Pre-commit tests for canonicalize negated operand of fdiv.
Mon, Jul 29, 9:11 AM

Jul 25 2019

cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.

I don't see a problem with scalarizing strict ops for Custom lowered nodes that would otherwise be legal. It's not ideal, I suppose, but if a target doesn't support the strict nodes in the backend, then it probably shouldn't be using the experimental intrinsics anyway.

Jul 25 2019, 10:16 AM · Restricted Project
cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

+1. What's the reason behind the scalarization?

Those are cases where the non-strict operation actually is not legal: e.g. the X86 target sets the operation action for FADD and FSUB vector operations to Custom. The old code simply ignored that and just emitted FADD and FSUB anyway as if they were legal, and only by chance did they match an isel pattern anyway.

The target can get the old behavior back by simply handling STRICT_FADD and STRICT_FSUB directly (presumably also via Custom operations similar to ones it uses for FADD/FSUB), so this is only a "regression" for the current fallback implementation.

Jul 25 2019, 9:09 AM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Another thought...

Jul 25 2019, 8:57 AM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Ok, I think we're pretty close to having unary FNeg optimizations in line with binary FNeg optimizations. Is anyone aware of any obvious passes that I've missed?

Jul 25 2019, 8:55 AM · Restricted Project

Jul 24 2019

cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

Jul 24 2019, 2:40 PM · Restricted Project

Jul 19 2019

cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

Makes sense to me. As I recall, the mutation was always intended as a temporary solution.

Jul 19 2019, 1:16 PM · Restricted Project

Jul 17 2019

cameron.mcinally updated subscribers of D64746: Add constrained intrinsics for lrint and lround.
Jul 17 2019, 8:44 AM · Restricted Project

Jul 16 2019

cameron.mcinally added inline comments to D64746: Add constrained intrinsics for lrint and lround.
Jul 16 2019, 1:24 PM · Restricted Project
cameron.mcinally added inline comments to D64746: Add constrained intrinsics for lrint and lround.
Jul 16 2019, 1:23 PM · Restricted Project
cameron.mcinally accepted D64412: [Strict FP] Allow more relaxed scheduling.

This patch would add the additional option of also changing the relative order of the two strict_fmul operations.

Jul 16 2019, 7:32 AM · Restricted Project

Jul 15 2019

cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

I think I'll have to challenge you a little here. ;)

Jul 15 2019, 2:25 PM · Restricted Project
cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

Bah, my last comment was flawed! I read the test cases incorrectly and missed the 'fpexcept.ignore' on some of them.

Jul 15 2019, 12:20 PM · Restricted Project
cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

I'm reviewing the trap-safety issues now and have some open questions (language lawyers needed??). Let's say we have something like this:

Jul 15 2019, 12:12 PM · Restricted Project

Jul 12 2019

cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

Is there any chance I can get this patch into 9? What do I need to do to make that happen?

Jul 12 2019, 10:40 AM · Restricted Project
cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

How aggressive is LLVM's UB handling? Would it remove an entire block/function if UB is found in it?

If LLVM can prove a basic block unconditionally executes UB, it will be erased. But "unconditionally" is an important qualifier. For example, consider the following function: void f(void g()) { g(); *(int*)0 = 0; }. The call to g isn't erased because we can't prove g will return.

Jul 12 2019, 8:05 AM · Restricted Project

Jul 9 2019

cameron.mcinally updated subscribers of D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
In D63782#1573780, @kpn wrote:

I might be opening a can of worms here and I'm not a language expert, but it isn't clear to me from reading the C99 standard that defining fptosi/fptoui as returning poison values in the unrepresentable case allows correct implementation of the C standard. That is, it doesn't seem to me that the standard actually says this is undefined behavior. It just says the resulting value is unspecified, and the exception behavior is explicitly defined. On the other hand, C++ does say clearly that it is undefined behavior, right?

Jul 9 2019, 9:47 AM · Restricted Project

Jul 8 2019

cameron.mcinally committed rG771769be9013: [Float2Int] Add support for unary FNeg to Float2Int (authored by cameron.mcinally).
[Float2Int] Add support for unary FNeg to Float2Int
Jul 8 2019, 7:49 AM

Jun 28 2019

cameron.mcinally added inline comments to D63933: [NewGVN] Add unary FNeg support to NewGVN pass.
Jun 28 2019, 2:40 PM · Restricted Project
cameron.mcinally committed rGb671535983fa: [NFC][NewGVN] Explicitly check fpmath metadata in fpmath.ll (authored by cameron.mcinally).
[NFC][NewGVN] Explicitly check fpmath metadata in fpmath.ll
Jun 28 2019, 2:40 PM
cameron.mcinally added inline comments to D63933: [NewGVN] Add unary FNeg support to NewGVN pass.
Jun 28 2019, 1:45 PM · Restricted Project
cameron.mcinally added inline comments to D63933: [NewGVN] Add unary FNeg support to NewGVN pass.
Jun 28 2019, 1:14 PM · Restricted Project
cameron.mcinally committed rG30e5cf1d8f3a: [NewGVN] Add unary FNeg support to NewGVN pass (authored by cameron.mcinally).
[NewGVN] Add unary FNeg support to NewGVN pass
Jun 28 2019, 1:11 PM
cameron.mcinally committed rGab4b2364e566: [GVNSink] Add unary FNeg support to GVNSink pass (authored by cameron.mcinally).
[GVNSink] Add unary FNeg support to GVNSink pass
Jun 28 2019, 12:58 PM
cameron.mcinally created D63941: [Float2Int] Add support for unary FNeg to Float2Int.
Jun 28 2019, 10:27 AM · Restricted Project
cameron.mcinally committed rG9fab46ca0bd3: [NFC][Float2Int] Pre-commit unary FNeg test to basic.ll (authored by cameron.mcinally).
[NFC][Float2Int] Pre-commit unary FNeg test to basic.ll
Jun 28 2019, 8:13 AM
cameron.mcinally created D63933: [NewGVN] Add unary FNeg support to NewGVN pass.
Jun 28 2019, 7:48 AM · Restricted Project
cameron.mcinally committed rG13d9c723c89b: [NFC][NewGVN] Pre-commit unary FNeg test to fpmath.ll (authored by cameron.mcinally).
[NFC][NewGVN] Pre-commit unary FNeg test to fpmath.ll
Jun 28 2019, 7:41 AM

Jun 27 2019

cameron.mcinally created D63900: [GVNSink] Add unary FNeg support to GVNSink pass.
Jun 27 2019, 2:49 PM · Restricted Project
cameron.mcinally committed rG30cab5d6eef7: [NFC][GVNSink] Pre-commit unary FNeg test to fpmath.ll (authored by cameron.mcinally).
[NFC][GVNSink] Pre-commit unary FNeg test to fpmath.ll
Jun 27 2019, 2:24 PM
cameron.mcinally committed rG6e62a796d502: [GVN] Add support for unary FNeg to GVN pass (authored by cameron.mcinally).
[GVN] Add support for unary FNeg to GVN pass
Jun 27 2019, 2:06 PM
cameron.mcinally created D63896: [GVN] Add support for unary FNeg to GVN pass.
Jun 27 2019, 1:48 PM · Restricted Project
cameron.mcinally committed rG22afca2ce022: [NFC][GVN] Pre-commit unary FNeg tests to fpmath.ll (authored by cameron.mcinally).
[NFC][GVN] Pre-commit unary FNeg tests to fpmath.ll
Jun 27 2019, 1:39 PM
cameron.mcinally added a comment to D54649: [FPEnv] Rough out constrained FCmp intrinsics.

Now that this has landed, are you planning to have another look at this?

Jun 27 2019, 12:46 PM · Restricted Project
cameron.mcinally updated subscribers of D63214: [InstCombine] canonicalize fmin/fmax to LLVM intrinsics minnum/maxnum.

This LGTM at a high level, but I don't fully understand the AVR concerns from D63294. Maybe @eli.friedman would be a better reviewer?

Jun 27 2019, 11:19 AM · Restricted Project

Jun 26 2019

cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

So pragmatically, an invalid exception is an alarm that the code is off track. As long as the exception is handled appropriately (default or an alternative), the result of the invalid operation shouldn't matter. Whatever LLVM wants to do with the value gets no arguments from me, since we've already self-destructed (unless the program handles the exception gracefully, but that wouldn't require a defined result from the invalid operation anyway).

But the exception could be masked couldn't it?

Jun 26 2019, 7:52 PM · Restricted Project
cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

I think IEEE-754 does define this

Your citation doesn't actually specify what value is returned, only that an exception is raised.

Jun 26 2019, 5:59 PM · Restricted Project
cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

Unless I'm misunderstanding, we should be leaving the constrained converts alone until a hardware instruction is produced.

We have to define the semantics; I mean, I guess we could say "If the value cannot fit in the destination type, the result is computed in a target-specific way", but we'd have to state it explicitly. And it's sort of awkward.

Jun 26 2019, 3:11 PM · Restricted Project
cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

What happens if the input float is out of range? fptosi/fptoui instructions produce poison; not sure if you want that here.

Jun 26 2019, 12:35 PM · Restricted Project

Jun 24 2019

cameron.mcinally committed rG1e5116cbb3a0: [NFC][Reassociate] Add unary FNeg tests to fast-ReassociateVector.ll (authored by cameron.mcinally).
[NFC][Reassociate] Add unary FNeg tests to fast-ReassociateVector.ll
Jun 24 2019, 2:38 PM
cameron.mcinally committed rGfe3f15cf9001: [SLP] Support unary FNeg vectorization (authored by cameron.mcinally).
[SLP] Support unary FNeg vectorization
Jun 24 2019, 12:25 PM
cameron.mcinally added a comment to D63609: [SLP] Support unary FNeg vectorization.

Answering myself - doesn't look like anything has changed since:
D62444 / rL361788

Jun 24 2019, 11:25 AM · Restricted Project

Jun 21 2019

cameron.mcinally added inline comments to D62158: [InstCombine] canonicalize minnum/maxnum with 'nnan' to fcmp+select.
Jun 21 2019, 11:09 AM · Restricted Project

Jun 20 2019

cameron.mcinally committed rG1c0bd6dd2ca7: [Reassociate] Remove bogus assert reported in PR42349. (authored by cameron.mcinally).
[Reassociate] Remove bogus assert reported in PR42349.
Jun 20 2019, 4:04 PM
cameron.mcinally updated the diff for D63609: [SLP] Support unary FNeg vectorization.

Add two more tests (X86/propagate_ir_flags.ll).

Jun 20 2019, 2:02 PM · Restricted Project
cameron.mcinally committed rG9589db7a98ea: [NFC][SLP] Pre-commit unary FNeg test to X86/propagate_ir_flags.ll (authored by cameron.mcinally).
[NFC][SLP] Pre-commit unary FNeg test to X86/propagate_ir_flags.ll
Jun 20 2019, 1:56 PM
cameron.mcinally created D63609: [SLP] Support unary FNeg vectorization.
Jun 20 2019, 9:34 AM · Restricted Project
cameron.mcinally committed rG4452c3b490e9: [NFC][SLP] Pre-commit unary FNeg test to X86/phi3.ll (authored by cameron.mcinally).
[NFC][SLP] Pre-commit unary FNeg test to X86/phi3.ll
Jun 20 2019, 8:16 AM

Jun 19 2019

cameron.mcinally committed rG11e7357a052d: [NFC][IR] Move CreateFNegFMF(...) next to CreateFNeg(...). (authored by cameron.mcinally).
[NFC][IR] Move CreateFNegFMF(...) next to CreateFNeg(...).
Jun 19 2019, 9:33 AM
cameron.mcinally committed rG7aa898e61e19: [DFSan] Add UnaryOperator visitor to DataFlowSanitizer (authored by cameron.mcinally).
[DFSan] Add UnaryOperator visitor to DataFlowSanitizer
Jun 19 2019, 8:09 AM
cameron.mcinally committed rGa027cf47640c: [Reassociate] Handle unary FNeg in the Reassociate pass (authored by cameron.mcinally).
[Reassociate] Handle unary FNeg in the Reassociate pass
Jun 19 2019, 7:57 AM

Jun 18 2019

cameron.mcinally accepted D63294: [Analysis] enhance FP library function prototype checking to match types with name suffix .

LGTM, assuming the test writer was not intentionally playing games with the fabs(...) calls.

Jun 18 2019, 9:09 AM · Restricted Project
cameron.mcinally added a comment to D62815: Add UnaryOperator visitor to DataFlowSanitizer.

Ping*2.

Jun 18 2019, 8:10 AM · Restricted Project
cameron.mcinally updated the diff for D63445: [Reassociate] Handle unary FNeg in the Reassociate pass.

Remove unintentional changes. Also fix up a poor naming choice.

Jun 18 2019, 7:39 AM · Restricted Project
cameron.mcinally added inline comments to D63445: [Reassociate] Handle unary FNeg in the Reassociate pass.
Jun 18 2019, 7:19 AM · Restricted Project

Jun 17 2019

cameron.mcinally updated the diff for D63445: [Reassociate] Handle unary FNeg in the Reassociate pass.

Correct comment. Should be 'nnan', not 'nnan and nsz'.

Jun 17 2019, 12:45 PM · Restricted Project
cameron.mcinally added a comment to D63405: GlobalISel: Don't lose fneg flags when lowering to fsub.

But there's a separate question that is raised here: why is it legal to convert fneg to fsub -0.0? That loosens the IEEE requirement when dealing with a NAN. I'd think this should be legalized by converting to integer and flipping the sign bit (xor).
ping @cameron.mcinally

Jun 17 2019, 12:45 PM
cameron.mcinally created D63445: [Reassociate] Handle unary FNeg in the Reassociate pass.
Jun 17 2019, 10:33 AM · Restricted Project

Jun 13 2019

cameron.mcinally committed rG79ec1a29572e: Revert "[NFC][CodeGen] Add unary fneg tests to fp-fast.ll fp-fold.ll fp-in… (authored by cameron.mcinally).
Revert "[NFC][CodeGen] Add unary fneg tests to fp-fast.ll fp-fold.ll fp-in…
Jun 13 2019, 12:26 PM
cameron.mcinally added a reverting change for rG1d85a7518c6b: [NFC][CodeGen] Add unary fneg tests to fp-fast.ll fp-fold.ll fp-in-intregs.ll…: rG79ec1a29572e: Revert "[NFC][CodeGen] Add unary fneg tests to fp-fast.ll fp-fold.ll fp-in….
Jun 13 2019, 12:26 PM
cameron.mcinally committed rG07514a1b1625: Revert "[NFC][CodeGen] Add unary fneg tests to fmul-combines.ll fnabs.ll" (authored by cameron.mcinally).
Revert "[NFC][CodeGen] Add unary fneg tests to fmul-combines.ll fnabs.ll"
Jun 13 2019, 12:26 PM
cameron.mcinally added a reverting change for rG5c0114058126: [NFC][CodeGen] Add unary fneg tests to fmul-combines.ll fnabs.ll: rG07514a1b1625: Revert "[NFC][CodeGen] Add unary fneg tests to fmul-combines.ll fnabs.ll".
Jun 13 2019, 12:26 PM
cameron.mcinally committed rG8984dbc27c37: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns_wide.ll" (authored by cameron.mcinally).
Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns_wide.ll"
Jun 13 2019, 12:26 PM
cameron.mcinally committed rG5d9271802ba6: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns.ll" (authored by cameron.mcinally).
Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns.ll"
Jun 13 2019, 12:25 PM
cameron.mcinally added a reverting change for rG06de52674da7: [NFC][CodeGen] Add unary fneg tests to X86/fma_patterns.ll: rG5d9271802ba6: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns.ll".
Jun 13 2019, 12:25 PM
cameron.mcinally added a reverting change for rGf1b8c6ac4f9d: [NFC][CodeGen] Add unary fneg tests to X86/fma_patterns_wide.ll: rG8984dbc27c37: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma_patterns_wide.ll".
Jun 13 2019, 12:25 PM
cameron.mcinally committed rGd331e71bdb67: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma4-fneg-combine.ll" (authored by cameron.mcinally).
Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma4-fneg-combine.ll"
Jun 13 2019, 12:25 PM
cameron.mcinally added a reverting change for rGf288a0685f87: [NFC][CodeGen] Add unary fneg tests to X86/fma4-fneg-combine.ll: rGd331e71bdb67: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma4-fneg-combine.ll".
Jun 13 2019, 12:25 PM
cameron.mcinally added a reverting change for rG3d2ee0053aa2: [NFC][CodeGen] Add unary fneg tests to X86/fma-scalar-combine.ll: rG31da4f80d5bb: Revert "[NFC][CodeGen] Add unary fneg tests to X86/fma-scalar-combine.ll".
Jun 13 2019, 12:25 PM