- User Since
- Oct 12 2016, 4:50 AM (153 w, 1 d)
I forgot to add the link to the differential review in the commit message. Adding the revision here:
Tue, Sep 17
Restore the function name to tryParseForVFABI.
I have removed the ParsedData struct as requested by @sdesmalen , my reasoning for keeping it was wrong.
Mon, Sep 16
Fri, Sep 13
This is a follow up patch to https://reviews.llvm.org/D66024
I added the Unknown ISA handling in the test ISAIndependentMangling, and updated the comments in the fuzzer.
I have split the implementation of VFShape into VFShape and VFInfo, as agreed.
Thu, Sep 12
I have updated the patch according to your feedback. In particular, I have modified all the parsing method to use the ParseRet enum instead of booleans. It looks better now, thanks.
Wed, Sep 11
I have deferred the handling of the mask token "M" to the VFParameter struct, introducing a new VFPAramKind that handles global function predication. This should be more in line with the aim of this implementation, which is to make VFShape independent from the Vector Function ABI. In particular, there are use cases that @simoll cares about where predication can be attached to single parameters, and not to the whole function.
In this new patch I have:
Tue, Sep 10
Mon, Sep 9
I have added the forward declaration.
I have done the following updates:
Thu, Sep 5
it would be better to parse the mangled string incrementally, rather than extracting each feature from the string individually.
I have updated the code according to the last round of reviews. I have removed pieces of code that were not needed anymore for testing.
Fri, Aug 30
Cosmetic changes to a comment.
I have uploaded a new version with the fuzzer requested by @lebedev.ri .
Wed, Aug 28
Jul 19 2019
Jun 4 2019
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.