Hi all,
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.
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?
Thanks,
Kyrill
