Displaying 3 results from an estimated 3 matches for "llvmvectortypekind".
2020 May 13
3
[llvm-commits@lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses]
...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<mailto: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 e...
2020 May 13
4
[llvm-commits@lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses]
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
2013 Sep 30
1
[LLVMdev] RFC: llvm-shlib-test (Was: [llvm] r191029 - llvm-c: Make LLVMGetFirstTarget a proper prototype)
Attached is what I got thus far.
What I'm struggling with is proper integration in build system. What
is in there is just wild guesses from my side, both on autoconf and
cmake variants. It would be great if someone with proper knowledge of
the buildsystems could have a look. Also I'm not sure how to properly
handle compilation on msvc - clearly "-std=c11 -Wstrict-prototypes" is