Page MenuHomePhabricator

wuzish (Zixuan Wu)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 18 2018, 9:45 PM (39 w, 3 d)

Recent Activity

Fri, Apr 19

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

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

Fri, Apr 19, 12:02 AM · Restricted Project
wuzish added a comment to D60854: [DAGLegalize][PowerPC] Add promote legalization of addc/adde and subc/sube.

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.

Fri, Apr 19, 12:02 AM · Restricted Project

Thu, Apr 18

wuzish added a comment to D60854: [DAGLegalize][PowerPC] Add promote legalization of addc/adde and subc/sube.

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?

Thu, Apr 18, 8:42 PM · Restricted Project

Wed, Apr 17

wuzish added reviewers for D60854: [DAGLegalize][PowerPC] Add promote legalization of addc/adde and subc/sube: craig.topper, tstellar.
Wed, Apr 17, 11:58 PM · Restricted Project
wuzish created D60854: [DAGLegalize][PowerPC] Add promote legalization of addc/adde and subc/sube.
Wed, Apr 17, 11:51 PM · Restricted Project

Sun, Apr 14

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.

Sun, Apr 14, 7:28 PM · Restricted Project

Fri, Apr 12

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

Thu, Apr 11

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…
Thu, Apr 11, 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…
Thu, Apr 11, 10:24 PM
wuzish closed D60181: [PowerPC] More precise exploitation of P9 maddld instruction when operands are constant.
Thu, Apr 11, 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.

Thu, Apr 11, 8:37 PM · Restricted Project

Tue, Apr 2

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

Thu, Mar 28

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…
Thu, Mar 28, 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…
Thu, Mar 28, 8:07 PM
wuzish closed D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Thu, Mar 28, 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.

Thu, Mar 28, 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.

Thu, Mar 28, 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.

Thu, Mar 28, 2:41 AM · Restricted Project

Tue, Mar 26

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

update code comments.

Tue, Mar 26, 11:27 PM · Restricted Project

Mon, Mar 25

wuzish added inline comments to D58950: [PowerPC] Strength reduction of multiply by a constant by shift and add/sub in place.
Mon, Mar 25, 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

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

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
wuzish closed D56077: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding causes mismatched register class.
Dec 27 2018, 6:16 PM
wuzish updated the diff for D56077: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding causes mismatched register class.

The patch is out-of-date of trunk. Rebase to trunk.

Dec 27 2018, 6:12 PM
wuzish updated the diff for D56077: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding causes mismatched register class.

Address comment from reviewer.

Dec 27 2018, 5:45 PM

Dec 25 2018

wuzish created D56077: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding causes mismatched register class.
Dec 25 2018, 6:30 PM
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 again

Dec 25 2018, 6:13 PM

Dec 16 2018

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...

Dec 16 2018, 7:02 PM

Dec 13 2018

wuzish created D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Dec 13 2018, 6:51 PM

Dec 6 2018

wuzish committed rL348566: [PowerPC] Fix assert from machine verify pass that missing undef register flag.
[PowerPC] Fix assert from machine verify pass that missing undef register flag
Dec 6 2018, 9:28 PM
wuzish closed D55408: [PowerPC] Fix assert from machine verify pass that missing undef register flag.
Dec 6 2018, 9:28 PM
wuzish created D55408: [PowerPC] Fix assert from machine verify pass that missing undef register flag.
Dec 6 2018, 8:54 PM

Nov 21 2018

wuzish accepted D54787: [PowerPC] Vector load/store builtins overstate alignment of pointers.
Nov 21 2018, 7:12 PM

Nov 15 2018

wuzish committed rL347019: [Clang][Sema]Choose a better candidate in overload function call if there is a….
[Clang][Sema]Choose a better candidate in overload function call if there is a…
Nov 15 2018, 7:02 PM
wuzish committed rC347019: [Clang][Sema]Choose a better candidate in overload function call if there is a….
[Clang][Sema]Choose a better candidate in overload function call if there is a…
Nov 15 2018, 7:02 PM
wuzish closed D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.
Nov 15 2018, 7:02 PM
wuzish retitled D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error from [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error to [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.
Nov 15 2018, 6:57 PM
wuzish updated the summary of D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.
Nov 15 2018, 6:20 PM

Nov 13 2018

wuzish added inline comments to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.
Nov 13 2018, 8:52 PM
wuzish updated the diff for D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

Use return type to distinguish which overload candidate is chosen because different candidate has different pointer return type which can not be converted implicitly without reporting error.

Nov 13 2018, 8:50 PM
wuzish committed rL346824: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
[PowerPC] Enhance the selection(ISD::VSELECT) of vector type
Nov 13 2018, 6:37 PM
wuzish closed D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 13 2018, 6:37 PM
wuzish updated the summary of D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 13 2018, 6:37 PM
wuzish added a comment to D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.

Gentle ping.

Nov 13 2018, 7:12 AM
wuzish added inline comments to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.
Nov 13 2018, 4:08 AM

Nov 12 2018

wuzish updated the diff for D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 12 2018, 2:49 AM
wuzish added inline comments to D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 12 2018, 2:48 AM

Nov 9 2018

wuzish added inline comments to D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 9 2018, 7:28 PM

Nov 8 2018

wuzish added a comment to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

The updated patch now extended the scope and can include the case.

Nov 8 2018, 11:26 PM
wuzish updated the diff for D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

Extend the scope to all vector type as one comment suggested.

Nov 8 2018, 11:20 PM
wuzish added a comment to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

I like the direction here, and I'd like to see this applied generally: a conversion sequence that bitcasts a vector should be ranked worse than one that does not, regardless of the kind of vector in use.

Nov 8 2018, 10:03 PM
wuzish committed rL346471: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be….
[PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be…
Nov 8 2018, 7:38 PM
wuzish committed rC346471: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be….
[PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be…
Nov 8 2018, 7:38 PM
wuzish closed D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element.
Nov 8 2018, 7:38 PM
wuzish closed D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element.
Nov 8 2018, 7:38 PM
wuzish updated the summary of D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element.
Nov 8 2018, 7:20 PM
wuzish added a comment to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

Gentle ping again since it's a critical patch. Could you please have a more review or give it LGTM if it's LGTM to you. Also welcome new comments.

Nov 8 2018, 1:54 AM
wuzish added a comment to D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.

I think it's a workaround that use vsel instead of xxsel for v16i8 and v8i16. So maybe we can change back in another patch after fix the encountered failures in check-all to make the selection consistently.

Nov 8 2018, 1:31 AM
wuzish requested review of D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 8 2018, 12:57 AM
wuzish updated the diff for D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 8 2018, 12:57 AM

Nov 5 2018

wuzish committed rL346202: It's a test commit, which is my first commit and also add my name to CREDITS.TXT.
It's a test commit, which is my first commit and also add my name to CREDITS.TXT
Nov 5 2018, 7:10 PM

Nov 4 2018

wuzish added inline comments to D49531: [PowerPC] Enhance the selection(ISD::VSELECT) of vector type.
Nov 4 2018, 10:15 PM
wuzish added a comment to D53417: [Clang][Sema]Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error.

Gentle ping. Could anyone else have a more review?

Nov 4 2018, 7:13 PM