Compilers at a fruit company
- User Since
- Sep 9 2013, 3:45 AM (219 w, 3 d)
Wed, Nov 8
Tue, Nov 7
Wed, Nov 1
Fri, Oct 27
Oct 15 2017
Can you not pass the -loop-interchange-threshold option to force the cost model to always interchange? If this isn't possible with the current code then it seems like a major oversight.
A minor nit but LGTM. I don't have an aversion to "dead code" if it's going to be used in the near future, so perhaps to make the patch smaller split it into an initial patch to add VPlanValue.h and then the VPlanBuilder.h as well as the changes to the documentation. Those pieces seem uncontroversial to me, before moving onto the vectorizer. @mkuper does this make sense?
Oct 11 2017
Oct 10 2017
I'm just curious, what's the issue with it returning a StringRef?
Oct 9 2017
Oct 8 2017
I haven't been keeping up with this area as much as I'd have liked, but have some comments. Overall the approach seems ok to me.
Oct 6 2017
Thanks, I've put the idiom into a helper and committed. Let me know if it's not what you had in mind.
Thanks, will do.
Rebased and updated diff to use a helper function for the overflow op result checks. I didn't put the type legal check into the helper because it's used to do an early exit rather than to continue onto the rest of the lower method.
Forgot to add llvm-commits, pasting description again:
Forgot to add llvm-commits.
Oct 5 2017
Oct 4 2017
Sep 30 2017
Sep 29 2017
Sep 28 2017
Committed test in r314416. Updated to show diff in behaviour.
Sep 27 2017
You mean actually commit the current codegen's test output (with no code changes) and then resubmit this patch as a diff?
Sep 25 2017
Sep 21 2017
Sep 13 2017
Aug 4 2017
Added support for handling the nsw/nuw ssub.with.overflow intrinsic.
The difference is that at the target codegen level we can't as easily do the predicate analysis as we can at the IR level.
If, for a particular target, it is worth emitting a versioned, carefully target-crafted loop or instruction sequence, I would expect them to not use this pass but to custom lower the calls in the backend much like x86 does for constant-size calls.
But in the patch description you say that one of the challenges is constructing *just* the right IR to get efficient codegen from the backend. I understand this is for x86 right now, but if you don't have plans to allow other targets to work well with it, why not put it into the Target/X86 directory and make it a backend-specific IR pass to avoid confusion?
Aug 2 2017
I'm resigning from SVE upstreaming related activities, so Graham will be taking over this patch and others from here.
Aug 1 2017
Instead of generating loop IR for the fast path, how about creating a versioned memcpy/memset with the constrained parameters guarded under the condition test? That way, in the back-end the exact preferred optimal code can be generated, allowing for unrolled loop bodies specific to individual targets.
Jul 31 2017
Updated to use MatchBinaryOp.
Jul 24 2017
Jul 23 2017
Jul 17 2017
Jul 13 2017
The reason it's removed is because it's not actually used anywhere, just as a default value. I'm not going to debate it further though so I've put it back in.
Ignore previous comment, was supposed to be added to D35118.
Jul 12 2017
Jul 11 2017
Jul 7 2017
Sure, up for review at D35118.