[llvm-dev] [cfe-dev] RFC: First-class Matrix type (original) (raw)
David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 12 02:02:04 PDT 2018
- Previous message: [llvm-dev] [cfe-dev] RFC: First-class Matrix type
- Next message: [llvm-dev] [cfe-dev] RFC: First-class Matrix type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11 Oct 2018, at 23:42, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
On the LLVM IR side, I'm personally unconvinced that we should model matrices in the IR directly as a new first-class type, unless there's some target out there that has matrix operations in hardware / matrix registers, but IR is not really my area of expertise so give that opinion as much or little weight as you see fit. However, I do wonder: how is this different from, say, complex numbers, for which we don't have a native IR representation? (Maybe the answer is that we should have native IR support for complex numbers too.) How would you expect the frontend to lower (eg) matrix multiplication for matrices of complex numbers?
I think there are a few potential problems with adding these into LLVM IR as a first-class type:
With vectors, we have a simple extension from scalar operations to vector ones. A scalar operation on a vector is exactly the same as the same scalar operation applied pairwise to the elements. This is not the case for matrix types.
A lot of analysis and transform passes need to have special cases for vectors. This is already a bit of a maintenance problem, but one that we put up with because of the big wins from vector types. Do matrix types have the same tradeoff?
What does a matrix of pointers look like? What is a GEP on a matrix of pointers? If I do GEP on a matrix of pointers and a matrix of integers and I replace it with ptrtoint, add, inttoptr, is that equivalent?
Does the IR representation enforce an in-memory representation? If different targets represent matrixes in different orders (e.g. column-major vs row-major) then how much do optimisers need to be aware of this?
Can all of the more complex operations that you might want to implement on matrixes be implemented in terms of a smaller number of primitives, without resorting to long extract and insert element sequences?
Can the same optimisations be used on sparse matrix representations that are then lowered by something custom nearer the back end?
As others have said, how does this interact with variable-sized matrixes?
David
- Previous message: [llvm-dev] [cfe-dev] RFC: First-class Matrix type
- Next message: [llvm-dev] [cfe-dev] RFC: First-class Matrix type
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]