Thank you @ABataev.
Mon, Apr 15
Fri, Apr 12
Thu, Apr 11
Wed, Apr 10
Hi! One of the tests was missing "REQUIRES: asserts", so it failed on a non-assert build. I took the liberty to add that to the test in r358057. I hope that was okay!
Tue, Apr 9
Thank you all.
@dcaballe , gentle ping.
Fri, Mar 29
I have addressed all concern raised in this review.
Should we add a small lit test that covers the new expected behavior? Probably reusing one from D57598 with the stress testing flag would suffice.
Thu, Mar 28
I have updated the patch to address all the concerns. Now VF = 4 for stress testing only if the computed VF does not produce vector code (VF < 2).
Yep, I agree on that we should keep the stress testing mechanism. It will be very useful to make sure that the construction and predication (and maybe other transformation) are robust enough since we can run it on loop nests that are not necessarily vectorizable.
Something important, though, is that we shouldn't use this mechanism to bypass legality or pragma simd requirements to vectorize a loop, i.e., we shouldn't use it to generate actual vector code.
What are you trying to achieve, Francesco?
I suggested removing setting VF = 4 for VPlanStressTest now that we programmatically determine the VF, to streamline things a bit. In a way, just have VPlanStressTest mean: build a VPlan for any loop you can, with the automatically chosen VF.
Wed, Mar 27
Thanks Francesco! I'll commit the change tomorrow, unless @hsaito does it today :)
I forgot to update the comment in the test as requested from @fhahn . Now it is done.
I have addressed last round of comments from @fhahn .
Fri, Mar 22
Mar 14 2019
Mar 13 2019
Addressed second round of comments from @hsaito.
I mostly changes to code to use the infrastructure that LLVM already provides to determine the vectorization factor.
Feb 4 2019
Thank you for looking into this.
Feb 1 2019
Dec 11 2018
Hello again - I have posted the RFC on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html
Is there a document that explains how to submit an RFC?
It's not that complex for a document. The text you have here would be more than fine, and the discussion that happened is exactly what we look for, but Phab reviews only copy llvm-commits, not llvm-dev, and that is the main problem.
Just to clarify - to me it is not clear whether I am required to create a new review on phabricator to be able to refer to this proposal as an RFC, and if so, which fields have to be set, and with which values, to make sure that the proposal is recognized as an official RFC by the LLVM community.
Dec 10 2018
I feel like pointing out that this RFC did *NOT* go to the lists, which makes zero sense, since it's RFC.
Nov 29 2018
Nov 27 2018
@hsaito , there are another couple of reasons for which I'd prefer to keep the -fveclib option.
Nov 26 2018
Nov 25 2018
I think i have addressed all your comments. Please let me know if I have missed anything.
Nov 20 2018
I am sorry for having kept you waiting for the patch. I was not fully aware of the approval process upstream (didn’t do much contributions upstream myself), and before being able to approve I had to understand the process.
Nov 19 2018
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
I still would like to see the ability to differentiate quasi-intrinsic veclib functions versus user-written vector functions and enable veclib w/o enabling user-written vector functions, even if -fopenmp-simd becomes default. Some of our ICC customers take perf data with and w/o openmp simd (and proprietary simd pragma) and they expect SVML to be used for both cases. I don't have much preferences in how to accomplish it. For example, if we'd like to keep the header file contents totally standard based, we could use something like a command line flag -fclang-vector-intrinsic=file1,file2,..,fileN to indicate that "declare simd" in those header file is "quasi-intrinsic". We could silently do this for the veclibs shipped with clang (e.g., check if "declare simd" is coming from clang include directory) ---- I'm fine with this ----, but that's a bit unfair to the 3rd party veclibs.
I would avoid having a clang-specific pragma. By just using the OpenMP one, we provide the library vendors with a mechanism that is based on a standard and therefore can be used by any compiler.
Nov 16 2018
Hi @steleman , thank you for your patience.
Nov 11 2018
Nov 9 2018
sorry for the delay in getting back to you. I have a couple of observations, for you and @shibatch.
Nov 2 2018
Nov 1 2018
OK, I like the idea of having a generalized way of expressing the libm <-> SLEEF bindings.
Oct 31 2018
Apologies for the confidentiality notice at the end my last message. It wasn't supposed to be there, please ignore it. Nothing of what I have written is confidential.
Hi @steleman , thank you for working on this!
Oct 30 2018
thank you for sending this out. I was wondering whether we really want to separate the concepts of vector lane predication and dynamic vector length.
Sep 26 2018
Mar 20 2018
Hi Matt - overall the patch looks good, I just have a couple of comments.
Jan 19 2018
Hi Matt, this is very nice. I have a couple of comments to add to Hal's one.
Nov 28 2017
Nov 6 2017
thank you for updating the patch.
Oct 23 2017
Hello - gentle ping on this patch. I think it is an important addition to the compiler. Do we need to reactivate the discussion in the mailing list?
Sep 1 2017
Aug 29 2017
This LGTM now.
Aug 24 2017
Apr 7 2017
thank you for reviewing this. If you don't mind, I will wait applying the changes you requested, Unfortunately I am not ready yet to send out an update as I am still working on the vector ABI. I will ping you when ready.
Mar 28 2017
Mar 23 2017
Mar 21 2017
Thanks, I do not have commit rights, can anyone commit this?
In principal looks good to me although I'm not really familiar with this part. Does that work for you if you have the declare simd in a header file and the implementation in another file? On x86_64 I currently get:
Mar 15 2017
Mar 14 2017
Mar 8 2017
- fixed formatting;
- added two tests that were missing.
Jan 23 2017
All, as we discussed, we agree to follow the GCC VectorABI and be GCC VectorABI compatible, right? It could be happened, I am looking at an old patch. Thanks.
This is just a rebase with a recent llvm codebase.
I have updated the patch to use the name mangling scheme we agreed - compatible with the GCC name mangling scheme.
Dec 12 2016
I have updated the name mangling of the associated vector function.
- Fix bug in copy constructor of the TargetLibraryInfoImpl class - I have missed copying out the multimap needed in the algorithm
- Fix bug in the TLII::mangle method (now it returns a std::string instead of a StringRef)
Dec 9 2016
I have removed all reviewers, this is not intended for code review.