- User Since
- May 15 2018, 2:45 AM (69 w, 5 d)
Thu, Sep 5
.AMDGPU also override the getCSRFirstUseCost() but your patch didn't catch that. And would you please post some improve number for powerpc of this patch ?
Aug 16 2019
We need to double check the base offset we select to avoid exceeding the 16-bit as much as possible
Aug 15 2019
LGTM except some minor comments.
Aug 14 2019
Only v4i32 is handled. We need to handle all the valid vector type.
Aug 12 2019
Aug 1 2019
LGTM with the update.
Jul 22 2019
The idea is great! Some comments.
Jul 21 2019
Abandon this revision, as most opportunity has been fixed by https://reviews.llvm.org/rL202451.
Jul 10 2019
Jul 7 2019
No. I didn't have the requirement to customer to cpu for the scheduler yet. I will abandon this patch and we can add the feature if we indeed find some cases that to do the customization.
Jul 4 2019
I am sorry that, I didn't put enough background for this change. The idea is not for per-function basis. We have the pre-ra scheduler and post-ra scheduler you know, and they should be able to be configured for different CPU processor. (Some cpu might need the post-ra scheduler, and some didn't, though we always enable it for all cpus) This is done by adding features and included by different cpu. And it also gives us the ability to turn on/off the specific scheduler.
Jul 1 2019
Jun 27 2019
Jun 25 2019
LGTM, with one minor comments. Maybe, you could commit a NFC patch to use "|=" instead of "=" to set the Simplified flag.
As talked, please confirm why we didn't set the Simplified flags. FWIK, this is a flag to indicate that, we have done some changes. We should set it.
As this was added by you in https://reviews.llvm.org/rL202451, would you please help me review this patch ? And I also commit another patch(https://reviews.llvm.org/D63318) to fold this pattern in DAGCombine. Would you please take a look together ? Thank you!
Jun 24 2019
Update the comments.
Jun 20 2019
Jun 19 2019
As the X86 review is done (Another issue exposed by this patch, and x86 backend will work on that ?), let's continue the review for the PowerPC backend and DAGCombine logic.
Jun 18 2019
Add the isZextFree check.
Jun 17 2019
Address reviewer's comments. Thank you!
Address reviewer's comments.
- Move the ctor to the header.
- Declare the SchedState as "class" instead of "struct" (Is it ok?).
- Rebase the patch to master and resolve the conflict.
Jun 14 2019
Jun 13 2019
Jun 9 2019
recommit the patch https://reviews.llvm.org/D61843 together with this one.
@RKSimon Thank you for your nice review!
Jun 5 2019
Address comments. Early return if it has been set before, to make the code more robust.
We cannot have the assertion, as it is possible that, it isn't set to something else(for example, this case). And the isBigEndian() check will fail if it isn't set to something else. However, in fact, we could do a check for each element, early return if it isn't set.
I have created the patch https://reviews.llvm.org/D62897 to fix this issue. @sbc100 Do you have any step for me to reproduce the broken ? I tried the c code you mentioned, didn't see the difference. And it would be great if you could try the patch of https://reviews.llvm.org/D62897 together with this one to see, if the broken fixed.
Jun 4 2019
I have never used the children-parent before. I just add it as parent revision now, no more action. This is what I want to do:
- commit this patch.
- rebase the parent revision patch and commit it. (I need to update the patch for that revision in theory)
May 30 2019
I will hold this patch until the test case update for systemZ is accepted. D62370: [NFC] Check the endianness after the CodeGenPrepare.
May 29 2019
Yes, I tried but decide not to reuse it. Because, the load pattern is trying to find out the load sequences that they are SHIFT and OR together, so, they have to walk the tree recursively to collect all the loads. But the store pattern is much easier. Because, We already know the stores from the chain. What we need to do is to check if all the store values are from some fixed pattern.
May 27 2019
Gentle ping ... Thank you!
May 24 2019
https://reviews.llvm.org/D62370 is created to update the test llvm/test/CodeGen/SystemZ/codegenprepare-splitstore.ll
May 23 2019
LGTM. But please hold on for some days if someone else might have comments.
May 21 2019
Address jinong's comments.
May 20 2019
Gentle ping ... Thank you!
LGTM, except some minor comments. However, please hold on for some days, if others have comments.
May 14 2019
May 13 2019
FYI. This is the thread of the discussion. http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html
That was discussed widely when https://reviews.llvm.org/D26149 is reviewed. This is the commit log saying something about the delay.
This optimization was discussed on llvm-dev some time ago in "Load combine pass" thread. We came to the conclusion that we want to do this transformation late in the pipeline because in presence of atomic loads load widening is irreversible transformation and it might hinder other optimizations.
May 12 2019
Gentle ping ...
May 8 2019
ok. Use the hasValue instead of the implicit bool convert operator to make the code clear.
May 4 2019
Update local variable name.
Apr 29 2019
Use opt instead of llc to do the check.
Apr 28 2019
@fhahn I have completed all the needed patches, and it would be great if you have the time to continue the review. This is the whole picture.
https://reviews.llvm.org/D61248 is the 1st patch to allow the schedule strategy to forward the schedule state between MBB.
https://reviews.llvm.org/D61249 is the 2nd patch to update the schedule strategy for SystemZ target to adapt with 1st patch.
https://reviews.llvm.org/D59480(this patch) is the 3rd patch to add the scheduled state data structure, so that, it could be kept somewhere.
https://reviews.llvm.org/D61250 is the last patch to forward the scheduled state 3rd patch added for PostGenericScheduler and enable it for PowerPC target.
Update the patch according to the reviewer comments.
Apr 27 2019
Apr 25 2019
Apr 15 2019
I am ok now for the doc part change. Thank you.
Apr 10 2019
Looks good, just one minor comments.
It seems that, we have already had the PowerPC section in the rst. It would be better to put them together.
PowerPC Language Extensions ------------------------------
Apr 7 2019
It would be great if we could add some documentation for these new added builtins, to make more people to know what we have done. i.e. clang/docs/LanguageExtensions.rst