Page MenuHomePhabricator
Feed Advanced Search

Today

wuzish added inline comments to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Tue, Sep 17, 12:33 AM · Restricted Project
wuzish updated the summary of D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Tue, Sep 17, 12:14 AM · Restricted Project

Yesterday

wuzish added inline comments to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Mon, Sep 16, 10:21 PM · Restricted Project
wuzish added inline comments to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Mon, Sep 16, 8:23 PM · Restricted Project
wuzish updated the diff for D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Change the interface prototype of getRegisterClassForType and make second parameter with default value.

Mon, Sep 16, 8:19 PM · Restricted Project

Sun, Sep 15

wuzish updated the diff for D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Address comments to simplify the default implementation for targets.

Sun, Sep 15, 11:31 PM · Restricted Project
wuzish added inline comments to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Sun, Sep 15, 11:02 PM · Restricted Project

Thu, Sep 12

wuzish updated the diff for D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Address comments. Add 3 function interfaces.

Thu, Sep 12, 3:25 AM · Restricted Project

Tue, Sep 10

wuzish added a comment to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Thanks for looking at this (it's been a problem for a long time). Let me suggest a different interface, which I believe will improve generality and reduce code duplication in the register-pressure estimator, and let me know what you think...

// Return the number of registers in the target-provided register class.
unsigned getNumberOfRegisters(unsigned ClassID = 0) const;
 
// Return the target-provided register class for the provided type.
unsigned getRegisterClassForType(Type *Ty) const;

The idea, then, is that we just calculate register usage for each register class separately (i.e., keep a hash table), and then when computing the interleaving factor, etc. we just iterate over all of the register classes returned by the target, and pick the smallest interleaving factor calculated over all of the register classes. There's probably even a nice way to construct a default implementation of this in the backend (although that we'd save for follow-up work).

Yes. Using ClassID is more general and fine-grained. But I think there is no need to iterate all kinds of register class because target register class is flexible and many register classes target provided are only different width with same position(such as gprc and g8rc), which makes too many kinds of register classes to maintain and some are just the same thing. It's not just use smallest interleaving factor calculated over all of the register classes and we also need to care about the overlapping relationship between different register class.

In all, it would be too fine-grained and little over-design, many register classes are just same behavior as separate with scalar and vector, int and float. What's your opinion?

I think that you misunderstood my suggestion. I did not mean that the backend register classes would be directly mapped into the classes returned by the TTI interface. These would, especially for non-trivial architectures, be abstracted for the purpose of the TTI interface. For PPC, Altivec, we'd have three class IDs for now (scalar float, scalar int, vectors), all with 32 registers. For VSX, we'd have two register class IDs, one for scalar ints (with 32 registers), and one for everything else (with 64 registers). (*) These don't need to have anything to do with the register classes actually defined in the backend. Do we need to capture finer-grained details than that in the heuristic (e.g. is your overlap suggestion capturing more than this)?

(*) Actually, for both cases, we can also have a separate class ID for scalar i1 types (with 8 registers).

Tue, Sep 10, 9:10 PM · Restricted Project
wuzish added a comment to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Thanks for looking at this (it's been a problem for a long time). Let me suggest a different interface, which I believe will improve generality and reduce code duplication in the register-pressure estimator, and let me know what you think...

// Return the number of registers in the target-provided register class.
unsigned getNumberOfRegisters(unsigned ClassID = 0) const;
 
// Return the target-provided register class for the provided type.
unsigned getRegisterClassForType(Type *Ty) const;

The idea, then, is that we just calculate register usage for each register class separately (i.e., keep a hash table), and then when computing the interleaving factor, etc. we just iterate over all of the register classes returned by the target, and pick the smallest interleaving factor calculated over all of the register classes. There's probably even a nice way to construct a default implementation of this in the backend (although that we'd save for follow-up work).

Tue, Sep 10, 8:00 PM · Restricted Project

Mon, Sep 9

wuzish added a comment to D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.

Gentle pin..

Mon, Sep 9, 10:34 PM · Restricted Project

Thu, Sep 5

wuzish added a comment to D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.

gentle pin...

Thu, Sep 5, 7:34 PM · Restricted Project
wuzish updated subscribers of D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.
Thu, Sep 5, 7:28 PM · Restricted Project

Wed, Sep 4

wuzish updated the summary of D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Wed, Sep 4, 2:08 AM · Restricted Project
wuzish updated the summary of D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Wed, Sep 4, 1:23 AM · Restricted Project
wuzish updated the summary of D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Wed, Sep 4, 1:10 AM · Restricted Project
wuzish created D67148: [LoopVectorize][PowerPC] Estimate int and float register pressure separately in loop-vectorize.
Wed, Sep 4, 12:50 AM · Restricted Project
wuzish accepted D66748: [PowerPC][Altivec][Clang] Check compile-time constant for vec_dst*.
Wed, Sep 4, 12:05 AM · Restricted Project, Restricted Project

Tue, Sep 3

wuzish accepted D66699: [PowerPC][Altivec] Fix constant argument for vec_dss.
Tue, Sep 3, 7:20 PM · Restricted Project, Restricted Project
wuzish committed rL370710: Request commit access for wuzish.
Request commit access for wuzish
Tue, Sep 3, 1:57 AM

Mon, Sep 2

wuzish added a reviewer for D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use: Restricted Project.
Mon, Sep 2, 10:20 PM · Restricted Project
wuzish added inline comments to D66699: [PowerPC][Altivec] Fix constant argument for vec_dss.
Mon, Sep 2, 8:16 PM · Restricted Project, Restricted Project
wuzish updated the summary of D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.
Mon, Sep 2, 1:05 AM · Restricted Project

Mon, Aug 26

wuzish added a comment to D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.

Could anybody run some bmk to see the performance result of AARCH64 and X86?
I have run on PowerPC, it has good influence in some bmks of spec2017 and no obvious degression.

Mon, Aug 26, 1:27 AM · Restricted Project
wuzish updated the diff for D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.

Enable it for AARCH64 and x86, and address testcases.

Mon, Aug 26, 1:22 AM · Restricted Project

Sun, Aug 25

wuzish committed rGe18aa1e0a2d3: [NFC][Regalloc] Add testcases for D66576 (authored by wuzish).
[NFC][Regalloc] Add testcases for D66576
Sun, Aug 25, 10:10 PM
wuzish committed rL369877: [NFC][Regalloc] Add testcases for D66576.
[NFC][Regalloc] Add testcases for D66576
Sun, Aug 25, 10:06 PM

Thu, Aug 22

wuzish added a comment to D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.

This is a WIP draft and I have not fixed all check-all cases now. I want to get some quick feedback whether it's on the right direction and whether its performance is good at all different target. If you have time, could you please review it or give some comments, and help me to verify the performance at other targets?

Thu, Aug 22, 1:18 AM · Restricted Project
wuzish created D66576: [Regalloc][WIP] Increase CSR cost in RegAllocGreedy to favour splitting/spill over CSR first use.
Thu, Aug 22, 1:13 AM · Restricted Project

Aug 15 2019

wuzish added inline comments to D65529: [PowerPC] Use xxleqv to set all one vector IMM(-1)..
Aug 15 2019, 1:30 AM · Restricted Project

Aug 14 2019

wuzish added a comment to D63152: [FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack.

Is there any fix patch proposed to track/fix the regression? @dnsampaio

Aug 14 2019, 3:34 AM · Restricted Project

Aug 12 2019

wuzish added a comment to D32201: [RALLOC] Increase CSR cost in RegAllocGreedy to favour splitting over CSR first use.
In D32201#1625379, @wmi wrote:

Should this good patch be rebased and continued to move on? @wmi
it'd be better to move on this work because D27366 is abandoned and D34608 is not updated for a long time, and those 3 patches are all trying to fix same issue and not landed successfully.
It would be great If it can land.

Thanks for bringing it to attention again.

I still think the patch will be very helpful for some cases especially when dynamic profile information is available (when FDO/SampleFDO is used). It is tricky if there is only static profile available. I will reevaluate the patch and see how it works if I change the patch to be functioning only when we have dynamic profile. If you are more interesting on the case when dynamic profile is not available -- i.e., try to make the patch more general, feel free to take over it and I will be happy to join discussion and review.

Aug 12 2019, 8:03 PM · Restricted Project
Herald added a project to D52709: Add -instcombine-code-sinking option: Restricted Project.

Wouldn't it better to pull it out of instcombine into.. let say.. CodeSinkingPass?

Absolutely. This code doesn't belong in InstCombine. This code isn't even the code we would use if we had a real sinking pass. This is a very simple sinking algorithm. It only moves code to an immediate successor and it has a bogus one use check in it. I think we should have a real sinking pass. lib/Transforms/Scalar/Sink.cpp is probably a good starting point, I believe its only used by one target today. I think adding a disable here is a good first step towards being able to experiment with a real sinking pass.

Aug 12 2019, 2:20 AM · Restricted Project

Aug 8 2019

wuzish added a comment to D32201: [RALLOC] Increase CSR cost in RegAllocGreedy to favour splitting over CSR first use.

Should this good patch be rebased and continued to move on? @wmi
it'd be better to move on this work because D27366 is abandoned and D34608 is not updated for a long time, and those 3 patches are all trying to fix same issue and not landed successfully.
It would be great If it can land.

Aug 8 2019, 2:58 AM · Restricted Project

Aug 5 2019

Herald added a project to D32201: [RALLOC] Increase CSR cost in RegAllocGreedy to favour splitting over CSR first use: Restricted Project.
Aug 5 2019, 10:35 PM · Restricted Project

Aug 4 2019

wuzish added a comment to D34608: [WIP][AArch64] Increase CSR cost when defering use of CSR is preferred.

Should this be rebased and continued to move on? Or it already could be addressed by https://reviews.llvm.org/D41765?

Aug 4 2019, 10:09 PM

Jul 31 2019

wuzish committed rG66c320908ba0: recommit:[PowerPC] Eliminate loads/swap feeding swap/store for vector type by… (authored by wuzish).
recommit:[PowerPC] Eliminate loads/swap feeding swap/store for vector type by…
Jul 31 2019, 10:27 PM
wuzish committed rL367516: recommit:[PowerPC] Eliminate loads/swap feeding swap/store for vector type by….
recommit:[PowerPC] Eliminate loads/swap feeding swap/store for vector type by…
Jul 31 2019, 10:25 PM
wuzish closed D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 31 2019, 10:25 PM · Restricted Project
wuzish added inline comments to D65529: [PowerPC] Use xxleqv to set all one vector IMM(-1)..
Jul 31 2019, 10:24 PM · Restricted Project
wuzish added a comment to D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.

Because we have PPCVSXSwapRemoval pass to hack the element order before P9 with vsx, the element order is not always standard normal order in register.
And the optimization of this patch will be conflict with PPCVSXSwapRemoval so that we can not get correct result during the process. The fix way is to not do this optmization before P9.

Jul 31 2019, 1:46 AM · Restricted Project
wuzish requested review of D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 31 2019, 1:37 AM · Restricted Project
wuzish reopened D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 31 2019, 1:37 AM · Restricted Project
wuzish updated the diff for D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.

update patch due to find issue.

Jul 31 2019, 1:36 AM · Restricted Project
wuzish added an edge to rG54d446f70e8a: revert r367382 because buildbot failure: D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 31 2019, 1:02 AM
wuzish added 1 commit(s) for D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store: rG54d446f70e8a: revert r367382 because buildbot failure.
Jul 31 2019, 1:02 AM · Restricted Project
wuzish committed rG54d446f70e8a: revert r367382 because buildbot failure (authored by wuzish).
revert r367382 because buildbot failure
Jul 31 2019, 12:04 AM
wuzish committed rL367388: revert r367382 because buildbot failure.
revert r367382 because buildbot failure
Jul 31 2019, 12:04 AM

Jul 30 2019

wuzish added an edge to rL367382: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big…: D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 30 2019, 8:04 PM
wuzish added 1 commit(s) for D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store: rL367382: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big….
Jul 30 2019, 8:04 PM · Restricted Project
wuzish closed D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.

Sorry to forget to add revision address in commit. Close it manually.

Jul 30 2019, 8:03 PM · Restricted Project
wuzish committed rGe85f6bf66c98: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big… (authored by wuzish).
[PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big…
Jul 30 2019, 7:59 PM
wuzish committed rL367382: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big….
[PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big…
Jul 30 2019, 7:55 PM
wuzish retitled D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store from [PowerPC] Eliminate loads feeding swaps for vector type by using big-endian load. to [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 30 2019, 7:54 PM · Restricted Project

Jul 29 2019

wuzish updated the diff for D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.

Commit testcase firstly and address comments.

Jul 29 2019, 11:16 PM · Restricted Project
wuzish added inline comments to D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 29 2019, 10:23 PM · Restricted Project
wuzish committed rGf940d859589f: [NFC][PowerPC] Add test case for D65063 (authored by wuzish).
[NFC][PowerPC] Add test case for D65063
Jul 29 2019, 10:22 PM
wuzish committed rL367283: [NFC][PowerPC] Add test case for D65063.
[NFC][PowerPC] Add test case for D65063
Jul 29 2019, 10:22 PM

Jul 26 2019

wuzish added inline comments to D34200: [PM/unswitch] Teach SimpleLoopUnswitch to do non-trivial unswitching, making it no longer even remotely simple..
Jul 26 2019, 12:17 AM · Restricted Project

Jul 25 2019

Herald added a project to D34200: [PM/unswitch] Teach SimpleLoopUnswitch to do non-trivial unswitching, making it no longer even remotely simple.: Restricted Project.
Jul 25 2019, 1:18 AM · Restricted Project

Jul 24 2019

wuzish added a comment to D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.

Gentle pin..

Jul 24 2019, 10:22 PM · Restricted Project

Jul 22 2019

wuzish committed rG57d17ec2e17b: [PowerPC] Replace float load/store pair with integer load/store pair when it's… (authored by wuzish).
[PowerPC] Replace float load/store pair with integer load/store pair when it's…
Jul 22 2019, 8:37 PM
wuzish committed rL366775: [PowerPC] Replace float load/store pair with integer load/store pair when it's….
[PowerPC] Replace float load/store pair with integer load/store pair when it's…
Jul 22 2019, 8:37 PM
wuzish closed D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.
Jul 22 2019, 8:37 PM · Restricted Project
wuzish added a comment to D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.

Gentle pin..

Jul 22 2019, 1:39 AM · Restricted Project

Jul 21 2019

wuzish created D65063: [PowerPC] Eliminate loads/swap feeding swap/store for vector type by using big-endian load/store.
Jul 21 2019, 10:26 PM · Restricted Project

Jul 17 2019

wuzish added a comment to D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.

After run bmk 2017 cpu for fortran and c/c++, there is some noise, no obvious degression. Some have little improvement about 1%~2%.

Jul 17 2019, 8:36 PM · Restricted Project
wuzish added a comment to D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.
Jul 17 2019, 8:24 PM · Restricted Project

Jul 16 2019

wuzish updated the diff for D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.

Address comments

Jul 16 2019, 1:31 AM · Restricted Project
wuzish committed rGa54c46674efb: [NFC][PowerPC] Add test case for D64195 (authored by wuzish).
[NFC][PowerPC] Add test case for D64195
Jul 16 2019, 12:59 AM
wuzish committed rL366191: [NFC][PowerPC] Add test case for D64195.
[NFC][PowerPC] Add test case for D64195
Jul 16 2019, 12:59 AM

Jul 15 2019

wuzish added a comment to D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.

gentle pin... It's a follow-up of https://reviews.llvm.org/D60601

Jul 15 2019, 1:24 AM · Restricted Project

Jul 4 2019

Herald added a reviewer for D51372: FENV_ACCESS support for libm-style constrained intrinsics: martong.
Jul 4 2019, 1:52 AM
wuzish created D64195: [PowerPC] Replace float load/store pair with integer load/store pair when it's only used in load/store.
Jul 4 2019, 1:11 AM · Restricted Project

Jul 3 2019

wuzish added a reviewer for D63916: [PowerPC] Add constraint fp support about exception part for operation +-*/ : kpn.
Jul 3 2019, 11:13 PM · Restricted Project
wuzish created D64193: [PowerPC] Add constraint fp support about exception part for remaining operations.
Jul 3 2019, 11:10 PM · Restricted Project
Herald added a reviewer for D52839: Inform AST's UnaryOperator of FENV_ACCESS: martong.
Jul 3 2019, 7:36 PM

Jul 1 2019

wuzish updated the diff for D63916: [PowerPC] Add constraint fp support about exception part for operation +-*/ .

update testcases.

Jul 1 2019, 11:00 PM · Restricted Project
wuzish committed rG7ae536a1cedf: [DAGCombiner] Exploiting more about the transformation of… (authored by wuzish).
[DAGCombiner] Exploiting more about the transformation of…
Jul 1 2019, 7:57 PM
wuzish committed rL364883: [DAGCombiner] Exploiting more about the transformation of….
[DAGCombiner] Exploiting more about the transformation of…
Jul 1 2019, 7:57 PM
wuzish closed D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jul 1 2019, 7:57 PM · Restricted Project
wuzish added inline comments to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jul 1 2019, 7:56 PM · Restricted Project
wuzish added inline comments to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jul 1 2019, 7:06 PM · Restricted Project

Jun 28 2019

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

I have another question about any_*.

For example, I see you use any_fadd to match both fadd and strict_fadd. I guess ZSystem target is similar to POWER that there is no fp addition machine instruction with nearest rounding mode and no exception statically.
But the semantic of fadd node requires. So theoretically, fadd node should be mapped into 2 instructions for correct compiling. One sets rounding mode to nearest and clear exception handler bit(no exception happens), the other is float addition.
Do we not handle fadd like above because there is no function error for such fine-grained instruction semantic mostly? And avoid performance penalty? @uweigand

I believe you may be misunderstanding the semantics of the non-strict operations. These do *not* instruct codegen to actively generate code to switch rounding modes and/or clear exception bits. Rather, the use of a non-strict operation like fadd is an *assertion* that tells codegen that it may *assume* that the rounding mode is set to default, trapping exceptions are switched off, and exceptions flags are don't care (i.e. subsequent code will not check them). If you ever use fadd in a context where this assumption is not true, the behaviour is undefined. This means it is perfectly correct to implement fadd using the "normal" floating-point instruction.

Note that similarly, if a strict operation with a given rounding mode flag is used, this likely does *not* instruct coegen to actively generate code to implement this particular rounding mode. Rather, this is again simply an *assertion* that tells codegen that it may *assume* the current rounding mode is set to this specific value. Again, this means that it is perfectly correct to implement such an operation using the "normal" floating-point instruction that will use the current rounding mode.

Jun 28 2019, 5:47 AM · Restricted Project

Jun 27 2019

wuzish added inline comments to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jun 27 2019, 8:29 PM · Restricted Project
wuzish added a reviewer for D63916: [PowerPC] Add constraint fp support about exception part for operation +-*/ : andrew.w.kaylor.
Jun 27 2019, 8:27 PM · Restricted Project
wuzish created D63916: [PowerPC] Add constraint fp support about exception part for operation +-*/ .
Jun 27 2019, 8:27 PM · Restricted Project
wuzish committed rG588a17097038: [NFC][PowerPC] Move XS*QP series instruction apart from XS*QPO series in… (authored by wuzish).
[NFC][PowerPC] Move XS*QP series instruction apart from XS*QPO series in…
Jun 27 2019, 7:52 PM
wuzish committed rL364620: [NFC][PowerPC] Move XS*QP series instruction apart from XS*QPO series in….
[NFC][PowerPC] Move XS*QP series instruction apart from XS*QPO series in…
Jun 27 2019, 7:51 PM
wuzish added inline comments to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jun 27 2019, 2:50 AM · Restricted Project
wuzish added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

I have another question about any_*.

Jun 27 2019, 2:14 AM · Restricted Project
wuzish added inline comments to D60601: [DAGCombiner] Exploiting more about the transformation of TransformFPLoadStorePair function.
Jun 27 2019, 12:17 AM · Restricted Project

Jun 25 2019

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

Is there any further step to enable the rounding-mode infra to handle rounding mode metadata in intrinsics? For example, covert rounding mode metadata to a new constant operand of strict_* series op. If some target/platform does not have related machine instruction for different static rounding-mode, then ignore this constant in td selection.

Jun 25 2019, 7:25 PM · Restricted Project

Jun 11 2019

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

Jun 5 2019

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.

Jun 5 2019, 7:10 PM

Jun 4 2019

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

Jun 2 2019

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

May 30 2019

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
May 30 2019, 9:41 PM