This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][benchtests] Accept output arguments to benchmark functions
- From: Will Newton <will dot newton at linaro dot org>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 4 Dec 2013 10:10:51 +0000
- Subject: Re: [PATCH][benchtests] Accept output arguments to benchmark functions
- Authentication-results: sourceware.org; auth=none
- References: <20131204073859 dot GO14845 at spoyarek dot pnq dot redhat dot com> <CANu=Dmj0zkujunQRQK_FvOQia0b_mT9O8NjsLm2WVEw9XC2sEw at mail dot gmail dot com> <20131204100640 dot GQ14845 at spoyarek dot pnq dot redhat dot com>
On 4 December 2013 10:06, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Wed, Dec 04, 2013 at 09:55:40AM +0000, Will Newton wrote:
>> On 4 December 2013 07:38, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
>> > Hi,
>> >
>> > This patch adds the ability to accept output arguments to functions
>> > being benchmarked, by nesting the argument type in <> in the args
>> > directive. It includes the sincos implementation as an example, where
>> > the function would have the following args directive:
>>
>> Is there a line missing here?
>
> Ugh, yeah there is. sincos would have the following args directive:
>
> ## args: double:<double *>:<double *>
>
> The above means that sincos takes three arguments of type double,
> double * and double *, where the last two arguments (enclosed with <>)
> are output arguments.
>
>>
>> It's not clear to me how these values map to the arguments / return values.
>>
>
> The values map only to the input arguments. So if I had a directive
> like this:
Ah, ok, makes sense, I was thinking that the output values were being
tested, but we're just benchmarking here so the values don't matter.
The patch looks ok to me.
--
Will Newton
Toolchain Working Group, Linaro