- User Since
- Nov 19 2012, 1:00 PM (432 w, 4 d)
Dec 2 2020
Nov 3 2020
Hi Dave. I have a quick question. Have you considered tuning the current cost model? What are the compile time implications of using VPlans?
Aug 12 2020
Aug 7 2020
Jul 27 2020
@craig.topper Good catch. Thank you. I've updated the diff.
Jul 26 2020
Jul 16 2020
Jul 15 2020
@wenlei You are right. SmallVector is a better fit. I updated the patch.
Jul 14 2020
@modocache Thank you for the review. I updated the permissions of the diff. Sorry, for the trouble.
Thank you. I will make the changes and try to commit the patch.
Oct 19 2018
Apr 29 2017
Apr 27 2017
Aug 16 2016
Aug 5 2016
Aug 3 2016
Aug 2 2016
Aug 1 2016
Jul 29 2016
Jul 4 2016
Ayal, I commented on the bug report that I don't understand why this heuristic is useful in the general case (for loops that are not this specific loop). Are you seeing any speedups on SPEC or the LLVM test suite (or other test suites?).
Jun 20 2016
Magnus, I don't have any problem with this change because it is specific to Erlang. I suggest CC-ing the original author of adjustForHiPEPrologue, and if that person has no objections commit the change. Relying on metadata is not idea, but I understand the constraint.
Jun 13 2016
May 10 2016
Mar 30 2016
Hal, the code looks much better. I was thinking about this patch on the way to work this morning and I was wondering if you could mark the type <4 x i32> as legal, because you _can_ load it and store it to memory. Right?
Mar 29 2016
I don't like the approach of passing in address-of-bool as parameter argument, especially since you did not document the parameter (is it IN, is it OUT, etc).
Hal, I am not sure I understand the problem. Is the problem register pressure or the fact that store <8 x i32> is more expensive than 8 times store i32?
Mar 2 2016
Feb 23 2016
The patch LGTM.
Feb 9 2016
Sorry for the delay in review. This patch LGTM.
Jan 28 2016
Jan 21 2016
Sounds good. Thanks Matthew.
Did you see any performance improvements due to this commit? Did you measure compile times?
Jan 12 2016
Dec 29 2015
Dec 21 2015
Elena, please fix the cost table and don't change anything else.
We don't let the instruction Sitofp <4 x i32 > %a to <4 x f64> go through the type legalizer.
Dec 20 2015
Elena, I don't understand your comment. getTypeLegalizationCost imitates the type legalizer by splitting and promoting. It actually uses the type legalizer. What do you mean it does not support zero-extend and sign-extend?
Dec 18 2015
Thanks for explaining this Elena. Have you considered handling all of the special cases by adding them to the 'TypeConversionCostTblEntry' table? Also, have you considered improving getTypeLegalizationCost?
Dec 17 2015
Dec 16 2015
Thanks for fixing this Charlie!
Dec 14 2015
It looks like this patch is not ready for review.
Dec 11 2015
@anemet In SelectionDAG we can use the memory order chains, and don't have to scan the whole basic block for loads/stores. This is very efficient, and is already used by the load-store merger in SelectionDAG.
Dec 6 2015
Nov 19 2015
Matthew, thanks for working on this.
Yes, we should merge this. LGTM!
Nov 12 2015
I did not get a chance to review this patch carefully. Andrea, Simon, David, Elena, Sanjay, did you get a chance to review the patch? Does it look okay? I did not see a LGTM in the thread.
Nov 9 2015
Nov 5 2015
Did you measure the performance impact of this patch on the llvm test suite (or SPEC or other test suite?). Is this a win?
Nov 2 2015
Oct 30 2015
Oct 27 2015
LGTM. Please commit.
Oct 26 2015
I don’t see a problem with this commit but please email llvm-commit and allow other developers to review this patch.
Okay. Please go ahead and commit this patch. I do have one minor comment:
I am okay with this change, but I have a few comments on the patch:
Oct 1 2015
What about SLP-vectorization of stores? I suspect that we have the same bug for stores.
Sep 25 2015
Aug 31 2015
I think that this is a good change. In many other places in the vectorizer the design was that we let other passes (such as CSE, InstCombine and LSR) clean up after us. I am totally okay with letting LSR do the cleanup. If I remember correctly we have always relied on LSR to do the cleanup and I don't remember why we have the logic for searching other induction variables.
Aug 20 2015
Maybe in a future patch we should refactor this logic in the SLP vectorizer and LoopVectorizer into a single function that verifies the metadata kind? I assume that the list should be identical.
Jul 29 2015
The code LGTM. Did you measure the compile time impact of this change?
Jul 6 2015
Sanjay, this patch looks okay. I think that the compile time hit should be minimal but I think that we need to measure just to be sure.
Jul 2 2015
Jun 19 2015
Jun 15 2015
Thanks for working on this. Did you run the llvm test suite? Are there any performance wins or compile time regressions?