- User Since
- Jul 30 2014, 7:37 PM (488 w, 19 h)
Feb 9 2019
LGTM with a suggestion
Oct 30 2018
Sorry for the delay. I think since most of the suggested changes are actually in a follow up patch. LGTM
Sep 18 2018
LGTM, but this patch may add a negligible increment on LLVM's compile time. Make sure you talk to some people that care about the LLVM compile time for their opinions
For some unclear reason rewriteLoopExitValues considers recalculation
after the loop profitable if it has some "soft uses" outside the loop (i.e. any
use other than call and return), even if we have proved that it has a user inside
the loop which we think will not be optimized away.
This also confuse me. Why it must be "soft uses" outside the loop that matter?
What I can guess is that, if there is no use outside, there is *no need* to rewrite the exit value.
Sep 17 2018
Sep 3 2018
LGTM in general.
Mar 7 2018
Jan 18 2018
Thanks, I will commit tonight. If you want this patch before that, you could commit it for me.
Address Hal's comment
Jan 17 2018
The original motivation is about hoisting the GEP, in general I want to GVN the gep like:
Implement isRegisterRich based on getNumberOfRegisters, and introduce a threshold to tell when the number of registers if big enough to be considered as "register-rich". Also include the usage of the isRegisterRich function in GVNHoist
Jan 3 2018
Nov 16 2017
Oct 14 2017
Oct 10 2017
Delete the redundant getSCEVAtScope
Oct 9 2017
Oct 7 2017
Oct 3 2017
Address reviewer comments
Partially address reviewer's comment. This is a WIP patch
Oct 2 2017
Sep 30 2017
Looks like I need to pass the SCEVExpander from the IndVarSimpilfy pass to coordinate SCEV rewrite, otherwise we will fail test/Transforms/IndVarSimplify/pr20680.ll
Address reviewer's comments
Sep 29 2017
Sep 26 2017
Sep 25 2017
address comments from the reviewer
Sep 21 2017
Sep 20 2017
update patch based on the comments
Update patch to address reviewer's request
Sep 19 2017
Aug 16 2017
Sorry this may be too late. Alexandre and me had discussed similar problem (but not exactly the same)
- maybe we could improve the ArgumentPromotion pass for this
- this pass seems to be generic, maybe we could move this to LLVM?
Aug 9 2017
Aug 7 2017
Aug 1 2017
Jul 25 2017
Jul 17 2017
Just out of curiosity, are we supposed to change the isl inside polly? what is the relationship between this isl and the "upstream" isl?
Jun 26 2017
May 11 2017
Address Tobias's comment
May 10 2017
Apr 28 2017
Apr 26 2017
Fix the test case.
I want to also include a test case, if you can point me to the test case related to IslNodeBuilder::preloadUnconditionally, I can add one.
Let me search polly test dir at the same time
Apr 25 2017
Mar 30 2017
fix the last few things before pushing the commit
This also sounds reasonable and I can also look at that after this.
Just a quick question: are we suppose to use getSCEVAtScope in getSCEV?
address sanjoy 's comment
Add more testcases
Mar 29 2017
Jan 30 2017
Jan 19 2017
Interesting, maybe we need to get this from TargetTransformInfo eventually, because I saw a similar global variable/option in LoadStoreVectorizer as well.
Jan 14 2017
Jan 11 2017
Jan 10 2017
Dec 22 2016
Oct 29 2016
This is pushed, phabricator didn't update this patch's status