[llvm-dev] [llvm-commits at lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses]
James Y Knight via llvm-dev
llvm-dev at lists.llvm.org
Wed May 13 11:30:16 PDT 2020
We can't guarantee everything. But, the goal is to not break things in the
C API, unless necessary. And, when it is necessary, to make sure it's as
obvious as possible of an ABI breakage. E.g., we might delete a
function, and create a new one with a new name, instead of incompatibly
changing the number of arguments for an existing function name. Or, might
leave a gap in enum values where an item is removed.
For your change, modifying the numeric values of the existing constants is
an unnecessary change, and a not-obvious ABI-incompatibility. Just
add LLVMScalableVectorTypeKind to the end, instead, and it's fine.
And, since the C API basically doesn't support scalable vectors yet, and
since you aren't modifying the rest of the C API's uses of "VectorType" to
FixedVectorType (e.g. the LLVMVectorType function is still named that), I'd
suggest simply leaving the enum value for Fixed vectors named
"LLVMVectorTypeKind" as it was before, instead of renaming it to
LLVMFixedVectorTypeKind.
On Wed, May 13, 2020 at 1:57 PM Chris Tetreault <ctetreau at quicinc.com>
wrote:
> Regarding the numerical value of the LLVMTypeKind enum, my understanding
> is that LLVM-C does not promise to maintain ABI compatability between
> versions. If I am mistaken, I can fix this issue.
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *James Y
> Knight via llvm-dev
> *Sent:* Wednesday, May 13, 2020 7:33 AM
> *To:* Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev at lists.llvm.org
> >
> *Subject:* [EXT] Re: [llvm-dev] [llvm-commits at lists.llvm.org: Re: [llvm]
> 2dea3f1 - [SVE] Add new VectorType subclasses]
>
>
>
> Agreed. Those llvm-c changes are wrong, and compatibility needs to be
> maintained for the numeric values at minimum. Probably also would be a good
> idea to make LLVMVectorTypeKind a deprecated alias
> for LLVMFixedVectorTypeKind.
>
>
>
> On Wed, May 13, 2020 at 9:11 AM Joerg Sonnenberger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Bringing this up on llvm-dev for more general attention.
>
> The problem here is two fold:
>
> (1) Reuse of enumeration values is just a major no-go.
> (2) I'm not sure why the existing vector types had to be killed
> completely.
>
> But something clearly has to be done here. This majorly affects e.g.
> Mesa.
>
> Joerg
>
> ----- Forwarded message from Joerg Sonnenberger via llvm-commits <
> llvm-commits at lists.llvm.org> -----
>
> Date: Sun, 10 May 2020 02:34:12 +0200
> From: Joerg Sonnenberger via llvm-commits <llvm-commits at lists.llvm.org>
> To: Christopher Tetreault <ctetreau at quicinc.com>, Christopher Tetreault <
> llvmlistbot at llvm.org>
> Cc: llvm-commits at lists.llvm.org
> Subject: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses
> Reply-To: Joerg Sonnenberger <joerg at bec.de>
>
> On Wed, Apr 22, 2020 at 08:59:20AM -0700, Christopher Tetreault via
> llvm-commits wrote:
> >
> > Author: Christopher Tetreault
> > Date: 2020-04-22T08:59:01-07:00
> > New Revision: 2dea3f129878e929e5d1f00b91a622eb1ec8be4e
> >
> > URL:
> https://github.com/llvm/llvm-project/commit/2dea3f129878e929e5d1f00b91a622eb1ec8be4e
> > DIFF:
> https://github.com/llvm/llvm-project/commit/2dea3f129878e929e5d1f00b91a622eb1ec8be4e.diff
> >
> > LOG: [SVE] Add new VectorType subclasses
>
> This seems to have basically broken both ABI and API of llvm-c.
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
> ----- End forwarded message -----
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200513/031e028a/attachment-0001.html>
More information about the llvm-dev
mailing list