Hi Jim,
Jim Wilson <j...@sifive.com> writes:
> On Tue, Nov 12, 2019 at 8:06 AM Richard Sandiford
> <richard.sandif...@arm.com> wrote:
>> If the use of sizeless types does expand beyond SVE built-in types
>> in future, the places that call the hook are the places that would
>> need to deal directly with sizeless types.
>
> We are using the same sizeless type infrastructure for the RISC-V
> vector extension work. The RVV extension is still in draft form and
> still evolving. The software is only in prototype form at the moment.
> We don't have an ABI yet. We have at least two competing proposals
> for the intrinsics based programming model. We don't have
> auto-vectorization support yet. Etc. But SiFive has been working on
> gcc patches for one of the intrinsics proposals, and EPI (European
> Processor Initiative) has been working on llvm patches for another
> intrinsics proposal, and both of these are using sizeless types. RVV
> has a similar design to ARM SVE where the size of types depends on the
> hardware you are running on, and those sizes can change at run-time,
> where they can be different from one loop iteration to the next.
Thanks for the heads-up. Glad to hear that this is useful more
generally than just SVE.
Are both RVV intrinsic proposals like SVE in that all sizeless types
can be/are built into the compiler? If so, do you think the target hook
added in:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00942.html
would be enough for RVV too? Or do the RVV proposals require support
for user-defined sizeless types?
If the hook is enough, I guess there are three ways we can go:
(1) Add hooks for both targets, with similar functionality. This means
a certain amount of cut-&-paste but also allows for more specific
error messages.
(2) Keep the hook (and so keep the frontend changes from the patch above),
but implement sizeless types in the default hook rather than
duplicating it in both backends.
(3) Go back to implementing this directly in the frontends, without a hook.
At this point I'd probably lean towards (1) if possible. Using the
hook ended up being a lot cleaner than I'd expected (IMO only of course),
and I've not seen any indication that (3) would be acceptable in the
near term. (And it's easy to see why. Sizeless types are a way of
supporting a target-specific built-in feature rather than a general
language extension, which is why personally I've been very reluctant
to try to get this standardised in C and C++. I just don't think that
can be justified yet, and comments I got from the WG14 reflector and
elsewhere bear that out. But that also probably influences whether
this should be done in the frontends, if (1) or (2) are viable
alternatives.)
Thanks,
Richard
