* Re: Travis build issue on PR #414
2018-04-10 15:09 ` Anthony Green
@ 2018-04-11 10:45 ` Anthony Green
0 siblings, 0 replies; 3+ messages in thread
From: Anthony Green @ 2018-04-11 10:45 UTC (permalink / raw)
To: Teodor Dermendzhiev; +Cc: libffi-discuss
Teodor, thank you for your contribution. I feel like we should discuss
this change in the list rather than in the PR in order to get wider
visibility, as this is an important change, and I'm hoping to elicit
feedback from others.
This patch adds support for clang's version of vectors, which are defined
using the ext_vector attribute (which is a clang-ism). My understanding
is that clang and GCC both have the concept of vectors that are roughly the
same, as they are used for simd computations. My first thought was... why
not just call it FFI_VECTOR instead of the clang specific FFI_EXT_VECTOR?
It turns out that there's at least one important difference between the
two compilers, and that it how vectors are aligned:
https://github.com/android-ndk/ndk/issues/640
The implementation of this features has us introducing what is essentially
a special case of FFI_STRUCT, which is handled differently when it comes to
argument passing. Other than that, it is treated as an FFI_STRUCT --
which also means that you are required to set all of the element types.
This seems suboptimal if we know that we're dealing with a vector of one
type.
libffi currently promises to set the size and alignment of your type
(specifically, aggregate types) for you, as they vary by ABI. However, the
current implementation allows you to set the size and alignment yourself,
which would appear to be a requirement given the different alignment
assumptions between GCC and clang. This is what your test cases do,
although they don't distinguish between GCC and clang alignment
assumptions. Is this correct?
So, some important questions...
1. Should we have FFI_GCC_VECTOR and FFI_CLANG_VECTOR (or FFI_EXT_VECTOR),
and have libffi fill in the size/alignment details as promised?
2. Should we just have FFI_VECTOR and force users to fill in the details
themselves because none of this is standardized?
3. Should we have something altogether different, and -- for instance --
only require the definition of one element type for vectors?
Also, at the very least, we need changes to libffi.texi to document
whatever is finally merged in.
Did I get this right? Any comments or suggestions from anyone?
Thanks,
AG
On Tue, Apr 10, 2018 at 11:09 AM, Anthony Green <green@moxielogic.com>
wrote:
> Thanks Teodor. I'll review your patch today. The travis errors are due
> to the 32-bit x86 multi-ABI problems, and unrelated.
>
> AG
>
>
> On Tue, Apr 10, 2018 at 10:42 AM, Teodor Dermendzhiev <
> Teodor.Dermendzhiev@progress.com> wrote:
>
>> Hello,
>>
>> Couple of weeks ago I submitted a PR targetting arm64 support for SIMD
>> types. After I fixed the errors from the Travis builds now it looks like
>> there is a problem there and I am not sure it is related to my changes.
>> Here (https://travis-ci.org/libffi/libffi/builds/364614226) you can see
>> all the builds but one are successful. According to the error log its
>> related to the log's size. It would be great to have some feedback on
>> this. Thank you.
>>
>> Greetings,
>> Teodor Dermendzhiev
>> NativeScript
>>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread