This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH x86-64][BZ #20024] Fixed vector sincos/sincosf ABI


2016-06-30 0:59 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> On Thu, 23 Jun 2016, Andrew Senkevich wrote:
>
>> +#define VECTOR_WRAPPER_fFF_2(scalar_func, vector_func)               \
>> +extern void vector_func (VEC_TYPE, VEC_INT_TYPE, VEC_INT_TYPE);      \
>> +void scalar_func (FLOAT x, FLOAT * r, FLOAT * r1)            \
>> +{                                                            \
>> +  int i;                                                     \
>> +  FLOAT r_loc[VEC_LEN], r1_loc[VEC_LEN];                     \
>> +  VEC_TYPE mx;                                                       \
>> +  VEC_INT_TYPE mr, mr1;                                              \
>> +  INIT_VEC_LOOP (mx, x, VEC_LEN);                            \
>> +  INIT_VEC_PTRS_LOOP (((FLOAT **) &mr), r_loc, VEC_LEN);     \
>> +  INIT_VEC_PTRS_LOOP (((FLOAT **) &mr1), r1_loc, VEC_LEN);   \
>> +  vector_func (mx, mr, mr1);                                 \
>> +  char *mr_ptr = (char *) &mr;                                       \
>> +  char *mr1_ptr = (char *) &mr1;                             \
>> +  TEST_VEC_LOOP (*((FLOAT **) mr_ptr), VEC_LEN);             \
>> +  TEST_VEC_LOOP (*((FLOAT **) mr1_ptr), VEC_LEN);            \
>> +  *r = *((FLOAT **) mr_ptr)[0];                                      \
>> +  *r1 = *((FLOAT **) mr1_ptr)[0];                            \
>
> I still think this is much more complicated than necessary.
>
> Rather than having variables mr_ptr and mr1_ptr at all, and having a load
> of pointer casts, I'd expect you just to pass r_loc and r1_loc - the
> arrays in which the results have been stored - directly to TEST_VEC_LOOP.
> And then store the results in *r and *r1 taken from r_loc[0] and
> r1_loc[0], without all the unnecessary indirection.

Indeed, it can be simplified now.

Is it  Ok with that change for trunk as well as for 2.22 and 2.23
release branches?


--
WBR,
Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]