Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
This revision was automatically updated to reflect the committed changes.
Closed by commit rL262385: This patch adds doxygen comments for the intrinsincs
in the header file… (authored by kromanova).
Changed prior to commit:
http://reviews.llvm.org/D17550?vs=48844&id=49534#toc
Repository:
rL LLVM
http://reviews.llvm.org/D17550
Files:
cfe/trunk/lib/Headers/popcntintrin.h
Index: cfe/trunk/lib/Headers/popcntintrin.h
===
--- cfe/trunk/lib/Headers/popcntintrin.h
+++ cfe/trunk/lib/Headers/popcntintrin.h
@@ -27,25 +27,65 @@
/* Define the default attributes for the functions in this file. */
#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,
__target__("popcnt")))
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_mm_popcnt_u32(unsigned int __A)
{
return __builtin_popcount(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_popcnt32(int __A)
{
return __builtin_popcount(__A);
}
#ifdef __x86_64__
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_mm_popcnt_u64(unsigned long long __A)
{
return __builtin_popcountll(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_popcnt64(long long __A)
{
Index: cfe/trunk/lib/Headers/popcntintrin.h
===
--- cfe/trunk/lib/Headers/popcntintrin.h
+++ cfe/trunk/lib/Headers/popcntintrin.h
@@ -27,25 +27,65 @@
/* Define the default attributes for the functions in this file. */
#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("popcnt")))
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_mm_popcnt_u32(unsigned int __A)
{
return __builtin_popcount(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_popcnt32(int __A)
{
return __builtin_popcount(__A);
}
#ifdef __x86_64__
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_mm_popcnt_u64(unsigned long long __A)
{
return __builtin_popcountll(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_popcnt64(long long __A)
{
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
That's fine, thanks.
On Tue, Mar 1, 2016 at 10:52 AM Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:
> Hi Dmitri,
> Thank you for your reply. I have double-checked that compiling a test
> invoking an intrinsic that has C++ style doxygen comments in the
> corresponding header doesn't cause compile-time errors/warnings in
> -std=c89 (and in gnu89, c99, gnu99, c11, gnu11) modes.
>
> I will continue committing the rest of the x86 inrinsics header files with
> C++-style doxygen comments, unless there are any other objections.
> Katya.
>
>
>
> > -Original Message-
> > From: Dmitri Gribenko [mailto:griboz...@gmail.com]
> > Sent: Tuesday, March 01, 2016 1:47 AM
> > To: Romanova, Katya
> > Cc: Eric Christopher;
> > reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Robinson,
> > Paul; Bedwell, Greg; cfe-commits@lists.llvm.org
> > Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM
> > intrinsics (part 6, popcntintrin.h)
> >
> > On Mon, Feb 29, 2016 at 10:59 AM, Romanova, Katya
> > wrote:
> > > Hi Dmitri,
> > >
> > > Could you please let us know your opinion about C++ vs C-style doxygen
> > > comments. Read this thread for ‘pro’ and ‘con’ arguments about using
> > > C++ headers. Will LLVM online documentation look proper if we decide
> > > to use C-style headers? Which style do you personally prefer to see?
> >
> > There are C comments that both Doxygen and Clang recognize well, equally
> > well to C++ comments.
> >
> > But I don't think that a change is necessary here. The reason is that
> these
> > are compiler-internal header files, so they will only be ever parsed by
> Clang.
> > No matter which mode Clang is in, it supports //-style comments, either
> as a
> > part of the language, or as an extension, I believe.
> >
> > While it is true that a pure c89 compiler won't be able to parse these
> > headers, we are not concerned about these builtin headers used by any
> > compiler other than Clang.
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j > (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
Hi Dmitri,
Thank you for your reply. I have double-checked that compiling a test invoking
an intrinsic that has C++ style doxygen comments in the corresponding header
doesn't cause compile-time errors/warnings in
-std=c89 (and in gnu89, c99, gnu99, c11, gnu11) modes.
I will continue committing the rest of the x86 inrinsics header files with
C++-style doxygen comments, unless there are any other objections.
Katya.
> -Original Message-
> From: Dmitri Gribenko [mailto:griboz...@gmail.com]
> Sent: Tuesday, March 01, 2016 1:47 AM
> To: Romanova, Katya
> Cc: Eric Christopher;
> reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Robinson,
> Paul; Bedwell, Greg; cfe-commits@lists.llvm.org
> Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM
> intrinsics (part 6, popcntintrin.h)
>
> On Mon, Feb 29, 2016 at 10:59 AM, Romanova, Katya
> wrote:
> > Hi Dmitri,
> >
> > Could you please let us know your opinion about C++ vs C-style doxygen
> > comments. Read this thread for ‘pro’ and ‘con’ arguments about using
> > C++ headers. Will LLVM online documentation look proper if we decide
> > to use C-style headers? Which style do you personally prefer to see?
>
> There are C comments that both Doxygen and Clang recognize well, equally
> well to C++ comments.
>
> But I don't think that a change is necessary here. The reason is that these
> are compiler-internal header files, so they will only be ever parsed by Clang.
> No matter which mode Clang is in, it supports //-style comments, either as a
> part of the language, or as an extension, I believe.
>
> While it is true that a pure c89 compiler won't be able to parse these
> headers, we are not concerned about these builtin headers used by any
> compiler other than Clang.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
On Mon, Feb 29, 2016 at 10:59 AM, Romanova, Katya
wrote:
> Hi Dmitri,
>
> Could you please let us know your opinion about C++ vs C-style doxygen
> comments. Read this thread for ‘pro’ and ‘con’ arguments about using C++
> headers. Will LLVM online documentation look proper if we decide to use
> C-style headers? Which style do you personally prefer to see?
There are C comments that both Doxygen and Clang recognize well,
equally well to C++ comments.
But I don't think that a change is necessary here. The reason is that
these are compiler-internal header files, so they will only be ever
parsed by Clang. No matter which mode Clang is in, it supports
//-style comments, either as a part of the language, or as an
extension, I believe.
While it is true that a pure c89 compiler won't be able to parse these
headers, we are not concerned about these builtin headers used by any
compiler other than Clang.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
Hi Dmitri, Could you please let us know your opinion about C++ vs C-style doxygen comments. Read this thread for ‘pro’ and ‘con’ arguments about using C++ headers. Will LLVM online documentation look proper if we decide to use C-style headers? Which style do you personally prefer to see? Note, that if there is any complaint in the future, it will take a couple of hours to write a python script to convert from C++ to C style doxygen comments. Katya. From: Eric Christopher [mailto:echri...@gmail.com] Sent: Wednesday, February 24, 2016 6:40 PM To: Romanova, Katya; reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Gao, Yunzhong; griboz...@gmail.com; craig.top...@gmail.com; Robinson, Paul Cc: Bedwell, Greg; cfe-commits@lists.llvm.org Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h) Those are all compelling reasons for me. Let's go with whatever you and Dmitri think would be best for now. :) -eric On Wed, Feb 24, 2016 at 12:41 PM Romanova, Katya mailto:katya_roman...@playstation.sony.com>> wrote: Hello, I don’t think it will too hard to convert C++ style doxygen comments into C style doxygen comments by writing a post-processing python script. However, at first we need to decide if we really want to do that. If so, we need to settle on the exact format. After that, I need to make sure that the comments in the new format will be rendered correctly in MS Tooltips, XCode, online documentation and PS4 internal documentation. This discussion + investigation might take a few days. Before we start discussing the exact format, I want to make sure that we really want to change to C-style doxygen comments. Here are my not-so-strong arguments against it: -There currently are 257 occurrences C++ style comments in 14 other header files in /llvm/tools/clang/lib/Headers directory (I’m talking about the files that I didn’t touch). C++ style comments were there for AGES and nobody complained so far. If we decide to change C++ style doxygen comments -> C-style, we also need to change all regular C++ comments to C-style in these header files. -c99 (and later) supports C++ style comments, while I c89 doesn’t. I’m not sure if we have users that still use c89 format and x86 intrinsic headers at the same time. -C++ style doxygen comments are more pretty and readable compared to C-style comment (though it might be my subjective opinion). Let me know what you think. I will try to get Dmitri Gribenko’s opinion. He did a lot of work on doxygen in LLVM. I’m curious what he thinks about Javadoc style format. Katya. From: Eric Christopher [mailto:echri...@gmail.com<mailto:echri...@gmail.com>] Sent: Tuesday, February 23, 2016 10:51 PM To: reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org<mailto:reviews%2bd17550%2bpublic%2bbc8ce213fd9db...@reviews.llvm.org>; Romanova, Katya; Gao, Yunzhong; griboz...@gmail.com<mailto:griboz...@gmail.com>; craig.top...@gmail.com<mailto:craig.top...@gmail.com>; Robinson, Paul Cc: Bedwell, Greg; cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org> Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h) Yeah, we should be doing this. Nice catch Paul and Greg. On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell mailto:greg_bedw...@sn.scee.net>> wrote: gbedwell added a subscriber: gbedwell. gbedwell added a comment. In http://reviews.llvm.org/D17550#360177, @probinson wrote: > One question I have, which shouldn't block this (as we've done several like > this already): > Is is okay to be using C++ style comments in these headers? > (Is there a C-style comment that Doxygen recognizes?) There are a few various formats that Doxygen supports. Looking at headers from llvm-c the most common convention appears to be JavaDoc style, although there are a few examples of other supported styles floating around the codebase. E.g. from include/llvm-c/lto.h using JavaDoc style: /** - Diagnostic handler type. - \p severity defines the severity. - \p diag is the actual diagnostic. - The diagnostic is not prefixed by any of severity keyword, e.g., 'error: '. - \p ctxt is used to pass the context set with the diagnostic handler. * - \since LTO_API_VERSION=7 */ -Greg Repository: rL LLVM http://reviews.llvm.org/D17550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
Those are all compelling reasons for me. Let's go with whatever you and Dmitri think would be best for now. :) -eric On Wed, Feb 24, 2016 at 12:41 PM Romanova, Katya < katya_roman...@playstation.sony.com> wrote: > Hello, > > > > I don’t think it will too hard to convert C++ style doxygen comments into > C style doxygen comments by writing a post-processing python script. > However, at first we need to decide if we really want to do that. If so, we > need to settle on the exact format. After that, I need to make sure that > the comments in the new format will be rendered correctly in MS Tooltips, > XCode, online documentation and PS4 internal documentation. This discussion > + investigation might take a few days. > > > > Before we start discussing the exact format, I want to make sure that we > really want to change to C-style doxygen comments. > > Here are my not-so-strong arguments against it: > > -There currently are 257 occurrences C++ style comments in 14 > other header files in /llvm/tools/clang/lib/Headers directory (I’m talking > about the files that I didn’t touch). C++ style comments were there for > AGES and nobody complained so far. If we decide to change C++ style doxygen > comments -> C-style, we also need to change all regular C++ comments to > C-style in these header files. > > -c99 (and later) supports C++ style comments, while I c89 > doesn’t. I’m not sure if we have users that still use c89 format and x86 > intrinsic headers at the same time. > > -C++ style doxygen comments are more pretty and readable compared > to C-style comment (though it might be my subjective opinion). > > > > Let me know what you think. > > > > I will try to get Dmitri Gribenko’s opinion. He did a lot of work on > doxygen in LLVM. I’m curious what he thinks about Javadoc style format. > > > > Katya. > > > > > > *From:* Eric Christopher [mailto:echri...@gmail.com] > *Sent:* Tuesday, February 23, 2016 10:51 PM > *To:* reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Romanova, > Katya; Gao, Yunzhong; griboz...@gmail.com; craig.top...@gmail.com; > Robinson, Paul > *Cc:* Bedwell, Greg; cfe-commits@lists.llvm.org > *Subject:* Re: [PATCH] D17550: Adding doxygen comments to the LLVM > intrinsics (part 6, popcntintrin.h) > > > > Yeah, we should be doing this. Nice catch Paul and Greg. > > > > On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell > wrote: > > gbedwell added a subscriber: gbedwell. > gbedwell added a comment. > > In http://reviews.llvm.org/D17550#360177, @probinson wrote: > > > One question I have, which shouldn't block this (as we've done several > like this already): > > Is is okay to be using C++ style comments in these headers? > > (Is there a C-style comment that Doxygen recognizes?) > > > There are a few various formats that Doxygen supports. Looking at headers > from llvm-c the most common convention appears to be JavaDoc style, > although there are a few examples of other supported styles floating around > the codebase. E.g. from include/llvm-c/lto.h using JavaDoc style: > > /** > > - Diagnostic handler type. > - \p severity defines the severity. > - \p diag is the actual diagnostic. > - The diagnostic is not prefixed by any of severity keyword, e.g., 'error: > '. > - \p ctxt is used to pass the context set with the diagnostic handler. * > - \since LTO_API_VERSION=7 */ > > -Greg > > > Repository: > rL LLVM > > http://reviews.llvm.org/D17550 > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
Hello, I don’t think it will too hard to convert C++ style doxygen comments into C style doxygen comments by writing a post-processing python script. However, at first we need to decide if we really want to do that. If so, we need to settle on the exact format. After that, I need to make sure that the comments in the new format will be rendered correctly in MS Tooltips, XCode, online documentation and PS4 internal documentation. This discussion + investigation might take a few days. Before we start discussing the exact format, I want to make sure that we really want to change to C-style doxygen comments. Here are my not-so-strong arguments against it: -There currently are 257 occurrences C++ style comments in 14 other header files in /llvm/tools/clang/lib/Headers directory (I’m talking about the files that I didn’t touch). C++ style comments were there for AGES and nobody complained so far. If we decide to change C++ style doxygen comments -> C-style, we also need to change all regular C++ comments to C-style in these header files. -c99 (and later) supports C++ style comments, while I c89 doesn’t. I’m not sure if we have users that still use c89 format and x86 intrinsic headers at the same time. -C++ style doxygen comments are more pretty and readable compared to C-style comment (though it might be my subjective opinion). Let me know what you think. I will try to get Dmitri Gribenko’s opinion. He did a lot of work on doxygen in LLVM. I’m curious what he thinks about Javadoc style format. Katya. From: Eric Christopher [mailto:echri...@gmail.com] Sent: Tuesday, February 23, 2016 10:51 PM To: reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Romanova, Katya; Gao, Yunzhong; griboz...@gmail.com; craig.top...@gmail.com; Robinson, Paul Cc: Bedwell, Greg; cfe-commits@lists.llvm.org Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h) Yeah, we should be doing this. Nice catch Paul and Greg. On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell mailto:greg_bedw...@sn.scee.net>> wrote: gbedwell added a subscriber: gbedwell. gbedwell added a comment. In http://reviews.llvm.org/D17550#360177, @probinson wrote: > One question I have, which shouldn't block this (as we've done several like > this already): > Is is okay to be using C++ style comments in these headers? > (Is there a C-style comment that Doxygen recognizes?) There are a few various formats that Doxygen supports. Looking at headers from llvm-c the most common convention appears to be JavaDoc style, although there are a few examples of other supported styles floating around the codebase. E.g. from include/llvm-c/lto.h using JavaDoc style: /** - Diagnostic handler type. - \p severity defines the severity. - \p diag is the actual diagnostic. - The diagnostic is not prefixed by any of severity keyword, e.g., 'error: '. - \p ctxt is used to pass the context set with the diagnostic handler. * - \since LTO_API_VERSION=7 */ -Greg Repository: rL LLVM http://reviews.llvm.org/D17550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
Yeah, we should be doing this. Nice catch Paul and Greg. On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell wrote: > gbedwell added a subscriber: gbedwell. > gbedwell added a comment. > > In http://reviews.llvm.org/D17550#360177, @probinson wrote: > > > One question I have, which shouldn't block this (as we've done several > like this already): > > Is is okay to be using C++ style comments in these headers? > > (Is there a C-style comment that Doxygen recognizes?) > > > There are a few various formats that Doxygen supports. Looking at headers > from llvm-c the most common convention appears to be JavaDoc style, > although there are a few examples of other supported styles floating around > the codebase. E.g. from include/llvm-c/lto.h using JavaDoc style: > > /** > > - Diagnostic handler type. > - \p severity defines the severity. > - \p diag is the actual diagnostic. > - The diagnostic is not prefixed by any of severity keyword, e.g., 'error: > '. > - \p ctxt is used to pass the context set with the diagnostic handler. * > - \since LTO_API_VERSION=7 */ > > -Greg > > > Repository: > rL LLVM > > http://reviews.llvm.org/D17550 > > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
echristo added a subscriber: echristo. echristo added a comment. Yeah, we should be doing this. Nice catch Paul and Greg. Repository: rL LLVM http://reviews.llvm.org/D17550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
gbedwell added a subscriber: gbedwell. gbedwell added a comment. In http://reviews.llvm.org/D17550#360177, @probinson wrote: > One question I have, which shouldn't block this (as we've done several like > this already): > Is is okay to be using C++ style comments in these headers? > (Is there a C-style comment that Doxygen recognizes?) There are a few various formats that Doxygen supports. Looking at headers from llvm-c the most common convention appears to be JavaDoc style, although there are a few examples of other supported styles floating around the codebase. E.g. from include/llvm-c/lto.h using JavaDoc style: /** - Diagnostic handler type. - \p severity defines the severity. - \p diag is the actual diagnostic. - The diagnostic is not prefixed by any of severity keyword, e.g., 'error: '. - \p ctxt is used to pass the context set with the diagnostic handler. * - \since LTO_API_VERSION=7 */ -Greg Repository: rL LLVM http://reviews.llvm.org/D17550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
probinson accepted this revision. probinson added a comment. This revision is now accepted and ready to land. LGTM. One question I have, which shouldn't block this (as we've done several like this already): Is is okay to be using C++ style comments in these headers? (Is there a C-style comment that Doxygen recognizes?) Repository: rL LLVM http://reviews.llvm.org/D17550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)
kromanova created this revision.
kromanova added a subscriber: cfe-commits.
kromanova set the repository for this revision to rL LLVM.
Here is the patch with the doxygen comments for the intrinsincs in the header
file popcntintrin.h.
The doxygen comments are automatically generated based on SCE internal
intrinsics document using DCG tool that I wrote.
I will submit more doxygen comments for the other intrinsic header files as
soon as this patch is approved.
Here is the link to the general discussion about adding comments to x86
intrinsics headers.
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032
Here are the links to the similar code reviews for the doxygen comments in some
other header files.
http://reviews.llvm.org/D8762 (closed)
http://reviews.llvm.org/D15999 (closed)
http://reviews.llvm.org/D16562 (closed)
http://reviews.llvm.org/D16913 (closed)
http://reviews.llvm.org/D17021 (closed)
Repository:
rL LLVM
http://reviews.llvm.org/D17550
Files:
popcntintrin.h
Index: popcntintrin.h
===
--- popcntintrin.h
+++ popcntintrin.h
@@ -27,25 +27,65 @@
/* Define the default attributes for the functions in this file. */
#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,
__target__("popcnt")))
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_mm_popcnt_u32(unsigned int __A)
{
return __builtin_popcount(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_popcnt32(int __A)
{
return __builtin_popcount(__A);
}
#ifdef __x86_64__
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_mm_popcnt_u64(unsigned long long __A)
{
return __builtin_popcountll(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_popcnt64(long long __A)
{
Index: popcntintrin.h
===
--- popcntintrin.h
+++ popcntintrin.h
@@ -27,25 +27,65 @@
/* Define the default attributes for the functions in this file. */
#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("popcnt")))
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_mm_popcnt_u32(unsigned int __A)
{
return __builtin_popcount(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///A signed 32-bit integer operand.
+/// \returns A 32-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ int __DEFAULT_FN_ATTRS
_popcnt32(int __A)
{
return __builtin_popcount(__A);
}
#ifdef __x86_64__
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c POPCNT instruction.
+///
+/// \param __A
+///An unsigned 64-bit integer operand.
+/// \returns A 64-bit integer containing the number of bits with value 1 in the
+///source operand.
static __inline__ long long __DEFAULT_FN_ATTRS
_mm_popcnt_u64(unsigned long long __A)
{
return __builtin_popcountll(__A);
}
+/// \brief Counts the number of bits in the source operand having a value of 1.
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to
