On Wed, 04 Sep 2024 19:24:41 PDT (-0700), Kito Cheng wrote:
Just remember adding a system wide vector calling convention has wide
compatible issues we need to worry about, like jump buf (for
setjmp/longjmp) will need to keep vector status, it doesn't need to
keep before since all vectors are call-clobber by default.
Also that may cause performance issue for vector, that will increase
the init cost for vector register - because part of vector reg become
callee save register now, so most case in current vector code gen
don't need backup/restore at prologue/epilogue, but it will change
once we change the default to vector calling convention by default.
Ya, I think we went through a bunch of that earlier on in vector land
when the design was still a bit vaguer and we weren't sure how it was
all going to fit together. Since it's a new ABI we don't have to worry
about cross-compatibility for the structs, so I think most of that stuff
is pretty managable (and I thought it was all in glibc, but sorry if I
missed something).
I think the trickiest bit is going to be the dynamic resolver, that was
the big thing that ended up being easy with the variant-only approach
-- and presumably we wouldn't want to tag everything as VARIANT_CC if
we're changing the system ABI, which IIRC this will end up doing.
So I would suggest system wilde should still keep using lp64d even
though the vector is available as one of the proposers for the vector
calling convention, but I am fine if the intention is having an option
to do some exercise or experiment.
Even if we were to merge it glibc would just break without support, so
IMO it's best to at least get a proof of concept for glibc before
merging anything.
Maybe we'll get lucky and this will trick a friendly glibc release
maintainer into doing it for us... ;)
On Thu, Sep 5, 2024 at 6:56 AM Jeff Law <jeffreya...@gmail.com> wrote:
On 9/4/24 2:26 PM, Palmer Dabbelt wrote:
> Now that we've got the riscv_vector_cc attribute it's pretty much free
> to add a system-wide ABI -- at least in terms of implementation. So
> this just adds a new ABI command-line value that defaults to enabling
> the vector calling convention, essentially the same as scattering the
> attribute on every function.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Add LP64DV.
> * config/riscv/riscv-d.cc (riscv_d_handle_target_float_abi):
> Likewise.
> * config/riscv/riscv-opts.h (enum riscv_abi_type): Likewise.
> * config/riscv/riscv.cc (riscv_vector_cc_function_p): Use
> LP64DV.
> (riscv_option_override): Likewise.
> * config/riscv/riscv.opt: Add LP64DV.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/lp64dv.c: New test.
> ---
> So this is very much an RFC, again. As such it's basically not tested,
> I just manually inspected the test case and it looks sane.
>
> This concept of a yes-V-by-default ABI has come up a bunch of times.
> There's some marginal performance benefit here (the added test saves a
> stack spill, for example). I have no idea how exciting this would be in
> real code, but I don't think having autovectorized values with lifetimes
> that cross function calls is super esoteric or anything. The
> implementation is basically free, though, and it seems kind of odd to
> just leave some performance on the floor for the sake of compatibility
> with the pre-official distro ABIs.
Well, that's really the question, isn't it. Will the distros pick it up
or not? If they don't, then it's just an academic exercise. I don't
think we've ever managed to get any kind of distro level buy-in on a
baseline architecture.
So I don't object to the idea, I just don't know if it's going to end up
being a dead end of effort or not.
Ya, I agree it's useless if it doesn't get used ;). It can't get used
if it doesn't exist, though, so it's kind of one of those
chicken-and-egg things. Hence the RFC...
jeff
