This is the mail archive of the
mailing list for the GCC project.
Re: target attributes/pragmas changing vector instruction availability and custom types
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: Christian Bruel <christian dot bruel at st dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 19 May 2015 17:09:02 +0100
- Subject: Re: target attributes/pragmas changing vector instruction availability and custom types
- Authentication-results: sourceware.org; auth=none
- References: <555B45F6 dot 4090902 at arm dot com> <555B4EE9 dot 1050603 at st dot com> <555B54F1 dot 3090703 at arm dot com>
On 19/05/15 16:21, Kyrill Tkachov wrote:
On 19/05/15 15:55, Christian Bruel wrote:
This is funny, I've updated bz65837 today in the same direction.
On 05/19/2015 04:17 PM, Kyrill Tkachov wrote:
I'm working on enabling target attributes and pragmas on aarch64 and I'm stuck on a particular issue.
I want to be able to use a target pragma to enable SIMD support in a SIMD intrinsics header file.
So it will look like this:
$ cat simd_header.h
#pragma GCC push_options
#pragma GCC target ("arch=armv8-a+simd")
<SIMD code, say SIMD intrinsics definitions>
#pragma GCC pop_options
I would then include it in a file with a function tagged with a simd target attribute:
$ cat foo.c
foo (uint32x4_t a)
return simd_intrinsic (a); //simd_intrinsic defined in simd_header.h and implemented by a target builtin
This works fine for me. But if I try to compile this without SIMD support, say: aarch64-none-elf-gcc -c -march=armv8-a+nosimd foo.c
I get an ICE during builtin expansion time.
I think I've tracked it down to the problem that the type uint32x4_t is a builtin type that we define in the backend
(with add_builtin_type) during the target builtins initialisation code.
From what I can see, this code gets called early on after the command line options have been processed,
but before target pragmas or attributes are processed, so the builtin types are laid out assuming that no SIMD is available,
as per the command line option -march=armv8-a+nosimd, but later while expanding the builtin in simd_intrinsic with SIMD available
the ICE occurs. I think that is because the types were not re-laid out.
I share this analysis.
I'm somewhat stumped on ideas to work around this issue.
I notice that rs6000 also defines custom builtin vector types.
Michael, did you notice any issue similar to what I described above?
Would re-laying the builtin vector type on target attribute changes be a valid way to go forward here?
this is what I've done on arm, seems to work locally.
for aarch64, you can try to call aarch64_init_simd_builtins () from your
target hook, then we need to think how to unset them.
Hmmm, calling aarch64_init_simd_builtin_types in the VALID_TARGET_ATTRIBUTE_P hook seems to work for me.
Actually, scratch that. I had used the wrong compiler. Calling the builtin init code through
the target attribute hook didn't work :(.
Looking further into int...
Thanks for the suggestion! I think undefining shouldn't be a concern since they are target-specific builtins and we make no guarantee on their availability or behaviour through any other use other than
the intrinsics in arm_neon.h. Of course, we'd need to massage the aarch64_init_simd_builtin_types to only
re-layout the types once, so that we don't end up doing redundant work or bloating memory.