On Tue, May 19, 2015 at 03:17:26PM +0100, Kyrill Tkachov wrote:
> Hi all,
Sorry, it took me awhile to comment.
> 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
> #inlcude "simd_header.h"
>
> __attribute__((target("arch=armv8-a+simd")))
> uint32x4_t
> 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.
We ran into this on the PowerPC. If you compile for 32-bit, the Altivec ABI is
not enabled by default. The compiler won't let you add VSX/Altivec target
options unless you compiled it with -mabi=altivec.
> 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'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?
You might look at the x86_64. When I was updating the target support for the
last global change affecting target support, I was pointed to mods that the
x86_64 folk had done. One of their mods is that they don't define all of the
built-in functions at compiler startup. Instead, they only add the built-in
functions that are allowed for the current set of switches. When a target
attribute or pragma adds new features, they go through the built-ins and add
any functions that were previously not added, but can now be added due to
having the appropriate target options enabled.
It helps avoid the big memory sync to create all ten million tree nodes for the
built-in functions for programs that don't use target attributes or pragmas.
It is something I thought about doing when I was working at AMD, and it looks
like they've done it now.
So if you are going to define all of the functions at compiler startup time
(like the PowerPC does), you have to define all of the types used, even the
current switches don't allow use of the types. Or you can only define what you
need, and when you change options, you go through and define any stuff that
wasn't previously defined that you can now use (like the current x86_64).
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
