- User Since
- Apr 6 2017, 8:36 AM (267 w, 4 d)
Feb 28 2022
Ping x2. Can you suggest who can I ask to review this?
Feb 22 2022
Feb 14 2022
Oct 11 2021
Oct 7 2021
LGTM other than a minor nit.
Sep 3 2021
Aug 30 2021
Rebase + ping
Aug 26 2021
Aug 24 2021
Aug 23 2021
Address Erich's comments
Hi guys, do you want me to fix anything else? I think I've addressed what I could.
Aug 20 2021
Fix a bug with not saving builder's insertion point.
Remove stale FIXME comment in the code being moved
Aug 19 2021
Apply reviewers' suggestions. Thanks!
Aug 16 2021
Another version. My main goal here is to gradually move more stuff from clang/
to llvm/ so I'm open to other suggestions in doing so.
Jul 15 2021
Jul 1 2021
The main alternative I see here is to use different logic for opaque pointers and always base them off an i8 element type
Jun 2 2021
Currently I am not sure how to best write a CHECK-line that will fail if a new successor gets added, e.g. CHECK: Successor(s): if.then.0 will also pass if an additional successor gets added. Perhaps we should just include the number of successors, something like 1 Successor: if.then, or 3 Successors: a, b, c.
Looks good to me. Thanks for following up on that.
Apr 30 2021
IIUC we will have non-recipe users in the future (e.g. live-outs)
Apr 26 2021
Apr 22 2021
VPlan part looks good to me. I'm not familiar with implementation details of the filtered_iterator to discuss the to_reference->filter->to_pointer approach though. Regardless of that, it's an improvement in interfaces, so LGTM unless someone has a way to make filtering work with pointer directly.
Apr 19 2021
I think it's functionally correct now, just have a few suggestions to simplify the code a little bit.
Apr 12 2021
LGTM, please wait a day or two to let others take a look.
Mar 19 2021
Mar 18 2021
It seems the code wasn't properly guarded before this change, and the proper fix would require changing too many places. I'd prefer to do it in separate patch.
Sorry for the troubles and thanks for reverting that for me - I didn't receive notifications from buildbots for it. Yes, it's probably related to those #ifs. I'm starting a Release build to reproduce and create a fix.
Mar 14 2021
Mar 12 2021
Address review comments.
Mar 11 2021
- Improve comments.
- Don't add a new dump point via cl::opt. Instead, add cl::opt to toggle behavior (dot/plain dumps) for the LVP::printPlans method.
Mar 9 2021
Mar 8 2021
Mar 4 2021
Mar 3 2021
I didn't recognize that it's still WIP until some point, so some nitpicking comments aren't very useful probably...
Mar 2 2021
Rebased on top of D97787.
Feb 25 2021
Feb 23 2021
Feb 16 2021
Move common implementation of get/set methods into helpers
Feb 12 2021
Feb 11 2021
Feb 1 2021
Jan 28 2021
Not blocking this review, but I think it's bug-prone to mix lane 0 of scalarized divergent values and truly uniform values that can be kept on a single scalar. Possible examples:
Hi Florian, I'm starting to familiarize myself with VPlan and wonder if that is a short/mid-term solution or something that is expected to be a long-term.
Jun 8 2020
Jan 21 2020
Ping. I don't see any comments that require action on my side.
Jan 15 2020
Remove target datalayout string from the test
Jan 14 2020
Pass tripple/target-cpu via opt's --triple/--mcpu options