- User Since
- Oct 12 2016, 4:50 AM (135 w, 6 d)
Apr 15 2019
Apr 12 2019
Thank you @ABataev.
Apr 11 2019
Apr 10 2019
Apr 9 2019
Thank you all.
@dcaballe , gentle ping.
Mar 29 2019
I have addressed all concern raised in this review.
Mar 28 2019
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).
Mar 27 2019
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 .
Mar 22 2019
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
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
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?
Mar 15 2017
Mar 14 2017
Mar 8 2017
- fixed formatting;
- added two tests that were missing.
Jan 23 2017
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.