On May 28, 2014, at 1:03 AM, Matthew Fortune <matthew.fort...@imgtec.com> wrote:

>> You shouldn't need to declare __builtin_* functions anyway.  And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in functions duplicating existing GNU C functionality.  (Look at
>> what AArch64 arm_neon.h does where possible, and what ARM arm_neon.h has
>> been moved towards lately.  I don't now what the msa.h functions do, so I
>> don't know if this actually applies to any of them - but it's something to
>> consider, so that built-in functions are only defined where actually
>> needed.)
> 
> In the aarch64 arm_neon.h header there are a decent number of inline asm
> implementations too instead of builtins. It is not immediately obvious to me
> as to what the deciding factor is between adding a builtin and using inline
> asm when vector extensions do not support the operation. Do you happen to
> know why inline asm is used in places?

Most likely simplify implementation at the time. Inline-asm is useless when it 
comes to scheduling code.  So the answer should be easy there. 


> 
> This looks like a reasonable idea to use GNU extensions where available. The
> down-side to this approach is that it may be necessary to write quite
> dis-similar headers for LLVM vs GCC which I think is part of the reason why
> the header is written as it is. I don't know if that is a good reason to
> require builtins or not though.

Well clang supports Opencl and Opencl got many of its vector behaviors from 
gcc. So I doubt it would be too hard for so ifdefs in there.

Thanks,
Andrew

> 
> Regards,
> Matthew

Reply via email to