Page MenuHomePhabricator

wuzish (Zixuan Wu)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 18 2018, 9:45 PM (48 w, 5 d)

Recent Activity

Tue, Jun 11

wuzish committed rGcc12f68fffa9: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC (authored by wuzish).
[PowerPC] [Clang] Port SSE2 intrinsics to PowerPC
Tue, Jun 11, 10:23 PM
wuzish committed rL363122: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
[PowerPC] [Clang] Port SSE2 intrinsics to PowerPC
Tue, Jun 11, 10:22 PM
wuzish closed D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Tue, Jun 11, 10:22 PM · Restricted Project, Restricted Project

Wed, Jun 5

wuzish added a comment to rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power.

That (controlling within the headers) sounds good to me. When that lands, then my understanding is that the PPCLinuxToolChain code would be adjusted to include ppc_wrappers in the search path in the general case. Please let me know if that's not the case. Thanks.

Wed, Jun 5, 7:10 PM

Tue, Jun 4

wuzish added inline comments to rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power.
Tue, Jun 4, 8:38 PM

Sun, Jun 2

wuzish updated the diff for D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Sun, Jun 2, 8:28 PM · Restricted Project, Restricted Project

Thu, May 30

wuzish committed rGfc3ed1ec5067: re-commit r361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC (authored by wuzish).
re-commit r361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC
Thu, May 30, 9:41 PM
wuzish committed rL362190: re-commit r361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
re-commit r361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC
Thu, May 30, 9:41 PM
wuzish closed D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
Thu, May 30, 9:40 PM · Restricted Project, Restricted Project
wuzish updated the diff for D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.

add test/CodeGen/ppc-mm-malloc-le.c, and use UNSUPPORTED: test flag to disable unsupport test of mm-malloc.

Thu, May 30, 8:27 PM · Restricted Project, Restricted Project
wuzish updated the diff for D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
Thu, May 30, 12:27 AM · Restricted Project, Restricted Project
wuzish commandeered D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
Thu, May 30, 12:27 AM · Restricted Project, Restricted Project

Wed, May 29

wuzish committed rG48061cd999a8: revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC (authored by wuzish).
revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC
Wed, May 29, 12:08 AM
wuzish committed rC361930: revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC
Wed, May 29, 12:08 AM
wuzish added a reverting change for rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC: rC361930: revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
Wed, May 29, 12:08 AM
wuzish committed rL361930: revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
revert rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC
Wed, May 29, 12:08 AM

Tue, May 28

wuzish updated subscribers of D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Tue, May 28, 11:37 PM · Restricted Project, Restricted Project
wuzish updated the summary of D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Tue, May 28, 10:40 PM · Restricted Project, Restricted Project
wuzish updated the summary of D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Tue, May 28, 10:40 PM · Restricted Project, Restricted Project
wuzish created D62569: [PowerPC] [Clang] Port SSE2 intrinsics to PowerPC.
Tue, May 28, 10:36 PM · Restricted Project, Restricted Project
wuzish committed rGb3bcbb5b6608: [PowerPC] [Clang] Port SSE intrinsics to PowerPC (authored by wuzish).
[PowerPC] [Clang] Port SSE intrinsics to PowerPC
Tue, May 28, 10:15 PM
wuzish committed rL361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
[PowerPC] [Clang] Port SSE intrinsics to PowerPC
Tue, May 28, 10:15 PM
wuzish committed rC361928: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
[PowerPC] [Clang] Port SSE intrinsics to PowerPC
Tue, May 28, 10:15 PM
wuzish closed D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.
Tue, May 28, 10:15 PM · Restricted Project, Restricted Project
wuzish added a reviewer for D62565: [PowerPC] Exploiting to use mtvsrdd instruction when save called-saved GPR register to VSR registers: jsji.
Tue, May 28, 8:24 PM · Restricted Project
wuzish created D62565: [PowerPC] Exploiting to use mtvsrdd instruction when save called-saved GPR register to VSR registers.
Tue, May 28, 8:21 PM · Restricted Project
wuzish added a comment to D62121: [PowerPC] [Clang] Port SSE intrinsics to PowerPC.

Thanks. I will commit for @qiucf

Tue, May 28, 7:59 PM · Restricted Project, Restricted Project

May 24 2019

wuzish added a comment to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.

Gentle pin....

May 24 2019, 1:00 AM · Restricted Project

Apr 29 2019

wuzish closed D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

https://reviews.llvm.org/rL359532
https://reviews.llvm.org/rG49d60fdc2e8e

Apr 29 2019, 8:09 PM · Restricted Project
wuzish committed rG49d60fdc2e8e: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the… (authored by wuzish).
[DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the…
Apr 29 2019, 8:03 PM
wuzish committed rL359532: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the….
[DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the…
Apr 29 2019, 8:03 PM
wuzish retitled D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node from [DAGCombiner] Do not do transforming of (trunc adde(X, Y, Carry)) -> (adde trunc(X), trunc(Y), Carry) when adde is not legal for the target to [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.
Apr 29 2019, 7:58 PM · Restricted Project
wuzish retitled D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node from [DAGLegalize][PowerPC] Add promote legalization of addc/adde and subc/sube to [DAGCombiner] Do not do transforming of (trunc adde(X, Y, Carry)) -> (adde trunc(X), trunc(Y), Carry) when adde is not legal for the target.
Apr 29 2019, 7:53 PM · Restricted Project
wuzish updated the diff for D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

update diff since it's out-of-date.

Apr 29 2019, 7:23 PM · Restricted Project

Apr 28 2019

wuzish added a comment to D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

@eli.friedman Could you please have a look again? :) Thanks a lot.

Apr 28 2019, 6:50 PM · Restricted Project

Apr 25 2019

wuzish updated the diff for D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

complete testcase

Apr 25 2019, 7:55 PM · Restricted Project

Apr 24 2019

wuzish updated the diff for D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.
Apr 24 2019, 8:22 PM · Restricted Project
wuzish added inline comments to D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.
Apr 24 2019, 7:56 PM · Restricted Project

Apr 23 2019

wuzish updated the diff for D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

If adde is not legal in target, do not combine to generate adde

Apr 23 2019, 11:39 PM · Restricted Project
Herald added a project to D39386: [Power9] Allow gpr callee saved spills in prologue to vector registers rather than stack: Restricted Project.
Apr 23 2019, 7:31 PM · Restricted Project

Apr 21 2019

wuzish added a comment to D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

In former condition, such transformation is acceptable even operation ADDE is illegal and it only cares about type legality because illegal operation will be legalized later in DAG legalization phase

Generally, yes, before operation legalization we can create illegal operations.

ADDE is sort of an exception, though; we don't have operation legalization support for it, and we don't want to add it. So the condition for the DAGCombine should be fixed.

Apr 21 2019, 10:19 PM · Restricted Project

Apr 19 2019

wuzish added a comment to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.

Gentle pin...
Anybody has any insights of this issue?

Apr 19 2019, 12:02 AM · Restricted Project
wuzish added a comment to D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

Oh, I see, we start with an i32 ADDE, then https://github.com/llvm/llvm-project/blob/e7fe6dd5edb828e702d02c7cdc6565ace4c84f5b/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L10232 narrows the operation. We probably shouldn't perform that transform if it would produce an illegal ADDE.

Apr 19 2019, 12:02 AM · Restricted Project

Apr 18 2019

wuzish added a comment to D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.

ADDC etc. are deprecated in favor of ADDCARRY. Nothing should generate ADDC etc. unless they're marked "Legal" for the type in question... and they should be Expand by default.

Could you look into where the node in question is getting generated?

Apr 18 2019, 8:42 PM · Restricted Project

Apr 17 2019

wuzish added reviewers for D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node: craig.topper, tstellar.
Apr 17 2019, 11:58 PM · Restricted Project
wuzish created D60854: [DAGCombiner] Do not generate ISD::ADDE node if adde is not legal for the target when combine ISD::TRUNC node.
Apr 17 2019, 11:51 PM · Restricted Project

Apr 14 2019

wuzish added a comment to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.

I can't find any previous discussion of this particular check. I agree it isn't necessary for correctness.

Do you have any benchmarks showing this actually helps? I'm a little concerned that this might not be a performance win in practice due to register pressure.

Apr 14 2019, 7:28 PM · Restricted Project

Apr 12 2019

wuzish added a reviewer for D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function: hfinkel.
Apr 12 2019, 2:32 AM · Restricted Project
wuzish updated the summary of D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Apr 12 2019, 2:28 AM · Restricted Project
wuzish created D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Apr 12 2019, 2:24 AM · Restricted Project

Apr 11 2019

wuzish committed rGac79ef8f0ec2: [PowerPC] More precise exploitation of P9 maddld instruction when operands are… (authored by wuzish).
[PowerPC] More precise exploitation of P9 maddld instruction when operands are…
Apr 11 2019, 10:25 PM
wuzish committed rL358253: [PowerPC] More precise exploitation of P9 maddld instruction when operands are….
[PowerPC] More precise exploitation of P9 maddld instruction when operands are…
Apr 11 2019, 10:24 PM
wuzish closed D60181: [PowerPC] More precise exploitation of P9 maddld instruction when operands are constant.
Apr 11 2019, 10:24 PM · Restricted Project
wuzish updated the diff for D60181: [PowerPC] More precise exploitation of P9 maddld instruction when operands are constant.

Address comments and make patch updated to the latest.

Apr 11 2019, 8:37 PM · Restricted Project

Apr 2 2019

wuzish created D60181: [PowerPC] More precise exploitation of P9 maddld instruction when operands are constant.
Apr 2 2019, 11:31 PM · Restricted Project

Mar 28 2019

wuzish committed rG1445b77e8c6d: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in… (authored by wuzish).
[PowerPC] Strength reduction of multiply by a constant by shift and add/sub in…
Mar 28 2019, 8:08 PM
wuzish committed rL357233: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in….
[PowerPC] Strength reduction of multiply by a constant by shift and add/sub in…
Mar 28 2019, 8:07 PM
wuzish closed D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Mar 28 2019, 8:07 PM · Restricted Project
wuzish updated the diff for D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

rebase patch based trunk because of out-of-date.

Mar 28 2019, 7:24 PM · Restricted Project
wuzish added a comment to D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

Gentle pin.

Mar 28 2019, 2:46 AM · Restricted Project
wuzish updated the diff for D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

address comments.

Mar 28 2019, 2:41 AM · Restricted Project

Mar 26 2019

wuzish updated the diff for D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

update code comments.

Mar 26 2019, 11:27 PM · Restricted Project

Mar 25 2019

wuzish added inline comments to D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Mar 25 2019, 7:23 PM · Restricted Project

Mar 19 2019

wuzish updated the diff for D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

Address comments and simplify the check pattern by using multiple prefixes.

Mar 19 2019, 12:13 AM · Restricted Project
wuzish added inline comments to D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Mar 19 2019, 12:12 AM · Restricted Project

Mar 10 2019

wuzish added a reviewer for D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place: stefanp.
Mar 10 2019, 11:50 PM · Restricted Project
wuzish added a comment to D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.

gentle pin...

Mar 10 2019, 11:50 PM · Restricted Project
wuzish committed rG428dcd5c3f2a: [PowerPC] Remove the override of isMachineVerifierClean() to open machine… (authored by wuzish).
[PowerPC] Remove the override of isMachineVerifierClean() to open machine…
Mar 10 2019, 8:33 PM
wuzish committed rL355798: [PowerPC] Remove the override of isMachineVerifierClean() to open machine….
[PowerPC] Remove the override of isMachineVerifierClean() to open machine…
Mar 10 2019, 8:33 PM
wuzish closed D59011: [PowerPC] Remove the override of isMachineVerifierClean() to open machine verifier.
Mar 10 2019, 8:33 PM · Restricted Project

Mar 6 2019

wuzish updated the summary of D59011: [PowerPC] Remove the override of isMachineVerifierClean() to open machine verifier.
Mar 6 2019, 11:36 PM · Restricted Project

Mar 5 2019

wuzish created D59011: [PowerPC] Remove the override of isMachineVerifierClean() to open machine verifier.
Mar 5 2019, 10:08 PM · Restricted Project

Mar 4 2019

wuzish created D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Mar 4 2019, 7:42 PM · Restricted Project

Feb 26 2019

wuzish added a comment to D45576: [RFC] Allow target to handle STRICT floating-point nodes.

Well, I have a question about why is it not enough to use use/def of physical register in MI level to prevent the reordering of instructions about set/get fp status register? For example, If the instruction which setting rounding mode, and then the instruction which read the rounding mode, the sequence would not be reordered because of the dependency of rounding mode bits (fp status register).

This would be enough to handle rounding-mode aspects. But if FP exceptions are enabled, we have additional restrictions: all FP exceptions could then have additional side effects (trap) and therefore cannot be executed speculatively, even where that would be OK from a status register dataflow perspective.

Also, one goal of the design is that we do not have to duplicate all FP instruction patterns in the back-end; we want a single pattern that can handle both the strict and non-strict case. If we wanted to a phys reg def, that would then have to be optional in some form, and there's no good way I can see to do this in the current infrastructure.

Feb 26 2019, 7:07 PM
wuzish added a comment to rG66b91e66ecc3: Implement necessary bits for flt_rounds gcc builtin. Codegen bits and llvm-gcc….

@wuzish Do you really wanted on comment on commit that is more than 10 years old? Have you looked over the current ToT?

Feb 26 2019, 3:01 AM
wuzish added a comment to D45576: [RFC] Allow target to handle STRICT floating-point nodes.

Well, I have a question about why is it not enough to use use/def in MI level to prevent the reordering of instructions about set/get fp status register. For example, If the instruction which setting rounding mode, and then the instruction which read the rounding mode, the sequence would not be reordered because of the dependency of rounding mode bits (fp status register).

Feb 26 2019, 2:08 AM
wuzish added a comment to rL44182: Implement necessary bits for flt_rounds gcc builtin. .

I think FLT_ROUNDS should add a chain as an operand because it has side effect, its result depends on outside state. So the ordering is matter.

Feb 26 2019, 1:34 AM
wuzish added a comment to rG66b91e66ecc3: Implement necessary bits for flt_rounds gcc builtin. Codegen bits and llvm-gcc….

I think FLT_ROUNDS should add a chain as an operand because it has side effect, its result depends on outside state. So the ordering is matter.

Feb 26 2019, 1:33 AM

Feb 25 2019

wuzish added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.
In D55506#1408913, @kpn wrote:

I think we can have a flag to indicate rounding mode for float operator such as FADD instead of STRICT_FADD, because STRICT_FADD does have side effect(chain), but some target (eg. RISCV) has static rounding mode encoded in the instruction which does not side effect. Then we can optimize specific STRICT_FADD node which ignoring exception into normal FADD with corresponding static round mode.

WRT the chain: "That's not a bug, that's a feature!"

The chain prevents reordering of floating point instructions by the SelectionDAG. That makes it required.

Some System/Z floating point instructions can take an optional per-instruction rounding mode encoded in the instruction. This does not eliminate the need for strict ordering of floating point operations.

Feb 25 2019, 6:23 PM · Restricted Project

Feb 24 2019

wuzish added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Well, mayRaise Exception is purely a MI level flag. I struggle to see where optimizations on the MI level would ever care about rounding modes in the sense you describe: note that currently, MI optimizations don't even know which operation an MI instruction performs -- if you don't even know whether you're dealing with addition or subtraction, why would you care which rounding mode the operation is performed in? MI transformations instead care about what I'd call "structural" properties of the operation: what are the operands, what is input vs. output, which memory may be accessed, which special registers may involved, which other side effects may the operation have. This is the type of knowledge you need for the types of transformations that are done on the MI level: mostly about moving instructions around, arriving at an optimal schedule, de-duplicating identical operations performed multiple times etc. (Even things like simply changing a register operand to a memory operand for the same operation cannot be done solely by common MI optimizations but require per-target support.)

On this level, I do believe that my proposed patch captures all relevant "structural" properties of floating-point instructions: dependency on control registers (including controlling changing rounding modes), and the possibility of floating-point exceptions and traps (affecting whether instruction may be rescheduled or executed speculatively). If you can think of anything I missed here, I'd certainly appreciate to learn more.

Now, of course, earlier passes (on the IR and also SelectionDAG levels) certainly do perform transformations that affect the actual operations performed, and those would certainly care. But at those levels we already have all the extra information we need; at the IR level we have the constrained intrinsics, and at the DAG level we have the STRICT_ nodes. (Currently, those STRICT_ nodes lose a bit of information available at the IR level: we don't specifically distinguish whether a STRICT_ node arose from an IR that is marked as requiring special handling because of just rounding modes, just exceptions, or both. If we ever want to add DAG optimization for STRICT_ node that requires this information, it would certainly be fine with me to add another bit in the SDNodeFlags for example.)

Feb 24 2019, 11:20 PM · Restricted Project

Jan 29 2019

wuzish committed rL352596: [PowerPC] [NFC] Create a helper function to copy register to particular….
[PowerPC] [NFC] Create a helper function to copy register to particular…
Jan 29 2019, 6:56 PM
wuzish closed D57368: [PowerPC] [NFC] Create a helper function to copy register to particular register class at PPCFastISel.
Jan 29 2019, 6:56 PM

Jan 28 2019

wuzish created D57368: [PowerPC] [NFC] Create a helper function to copy register to particular register class at PPCFastISel.
Jan 28 2019, 9:21 PM

Jan 24 2019

wuzish committed rL352174: [PowerPC] Enhance the fast selection of cmp instruction and clean up related….
[PowerPC] Enhance the fast selection of cmp instruction and clean up related…
Jan 24 2019, 11:25 PM
wuzish closed D57078: [PowerPC] Enhance the fast selection of cmp instruction and clean up related asserts.
Jan 24 2019, 11:25 PM

Jan 23 2019

wuzish added a comment to D57078: [PowerPC] Enhance the fast selection of cmp instruction and clean up related asserts.

gentle pin 😄

Jan 23 2019, 11:22 PM

Jan 22 2019

wuzish updated the diff for D57078: [PowerPC] Enhance the fast selection of cmp instruction and clean up related asserts.

Make patch up-to-date.

Jan 22 2019, 7:31 PM
wuzish created D57078: [PowerPC] Enhance the fast selection of cmp instruction and clean up related asserts.
Jan 22 2019, 7:12 PM

Jan 9 2019

wuzish committed rL350799: Recommit "[PowerPC] Fix assert from machine verify pass that unmatched register….
Recommit "[PowerPC] Fix assert from machine verify pass that unmatched register…
Jan 9 2019, 10:24 PM
wuzish closed D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Jan 9 2019, 10:24 PM
wuzish updated the diff for D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.

use copy to resolve the mismatch instead of assert.

Jan 9 2019, 2:17 AM

Jan 8 2019

wuzish committed rL350693: Revert "[PowerPC] Fix assert from machine verify pass that unmatched register….
Revert "[PowerPC] Fix assert from machine verify pass that unmatched register…
Jan 8 2019, 10:16 PM
wuzish reopened D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Jan 8 2019, 10:11 PM
wuzish committed rL350685: [PowerPC] Fix assert from machine verify pass that unmatched register class….
[PowerPC] Fix assert from machine verify pass that unmatched register class…
Jan 8 2019, 6:35 PM
wuzish closed D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Jan 8 2019, 6:34 PM

Jan 6 2019

wuzish added a comment to D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.

Gentle ping for new update

Jan 6 2019, 10:11 PM

Jan 2 2019

wuzish added inline comments to D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Jan 2 2019, 7:46 PM
wuzish updated the diff for D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.

Address comment

Jan 2 2019, 7:42 PM

Dec 27 2018

wuzish committed rL350114: [NFC] clang-format functions related to r350113.
[NFC] clang-format functions related to r350113
Dec 27 2018, 6:49 PM
wuzish committed rL350113: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding….
[PowerPC] Fix assert from machine verify pass that atomic pseudo expanding…
Dec 27 2018, 6:16 PM