- User Since
- Oct 12 2016, 4:50 AM (110 w, 23 h)
Tue, Nov 20
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.
Mon, Nov 19
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.
Fri, Nov 16
Hi @steleman , thank you for your patience.
Sun, Nov 11
Fri, Nov 9
sorry for the delay in getting back to you. I have a couple of observations, for you and @shibatch.
Fri, Nov 2
Thu, Nov 1
OK, I like the idea of having a generalized way of expressing the libm <-> SLEEF bindings.
Wed, Oct 31
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!
Tue, Oct 30
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.
I have removed all reviewer, this is not intended for code review.
Dec 5 2016
Nov 30 2016
I updated the comments related to code formatting.
Rebase plus clang format.
Rebase plus apply clang format.