[TCDG] Minutes of 2025-03-19 meeting

MLIR Tensor Compiler
1

Hereby the minutes/meeting notes from this Wednesday’s Tensor Compiler Design Group meeting.

The main topics all concerned proposed changes to the vector dialect:

  • Rolf proposed changing TilingInterface to facilitate tiling/register blocking on ops on vectors. After discussion the approach by which we make the interface abstract enough so that it’s main driver, tileUsingSCF, does not need to care if it is operating on particular ShapedTypes, such as tensor or memref, was considered to have some merit (e.g. as it will also lessen/remove scf’s dependency on tensor and memref). A RFC will follow.
  • Jakub raised a procedural point: how do discussion in these meetings related to the more established, more public process? The emerging answer is that these meetings serve well for rapid feedback before engaging in the conventional fully public RFC process.
  • On behalf of Kunwar, Jakub asked about whether syntactic (& verifier) changes to masked load and masked store were considered alright. Preferences differed, though none seemed to have a strong opinion.
  • Diego raised the question of allowing vectors with pointer element types. The proposal by Matthias is to introduce an interface for PointerLike types. The RFC has now been posted.
  • On behalf of Kunwar, Quinn brought up Kunwar’s existing RFC and how dropping indexing and permutation maps might be in order. Upshot was that Kunwar is to send an update on extending vector.gather + vector.scatter instead.

The following is a copy of the Meeting’s Agenda, Minutes and Actions:

Agenda:

Minutes:

  • [Rolf] (continuing on from previous meeting:) tiling/blocking on vector, now focused on extending TilingInterface to allow for more implementers, in particular those that operate on vector type. Main motivation is being able to introduce loops at same level as they are in ukernel libraries (i.e. to do the same codegen in the compiler) in the context of not being able to have the pipeline pass through linalg (without onerous raising, that is. IR coming out of Triton/Triton-CPU being just one example of such a pipeline).

    • [Quinn] Dynamic sizes will just not be supported on vector tiling
      • Issue with dynamic offsets on extract/insert_strided_slice → see vector dialect docs
    • [Andrzej] Is that also relevant to scalable dims on vector?
    • [Matthias] Can we move to ShapedType for TilingInterface?
      • [Rolf] Yes, this would be the preferred approach
    • [Quinn] Non-perfect division is going to lead to unwanted dynamism
    • [Andrzej] Do we really need support for loop transformations at the vector level given that there are (supposed to be) other, higher-level mechanisms?
      • [Rolf] It would be desirable to have the vector charter be explicit about, in particular to motivate why this should or should not be allowed (given the context of not being able pass through linalg)
    • [Diego] If the TilingInterface is extended to vector ops, how much overlap with linalg will we get? How much overlap do we want to allow?
      • [Rolf] For now we just want to extend TilingInterface to allow for ops at the vector-level to implement the interface. Making upstream vector ops implement the interface implement it by default is matter to revisit when the approach has proven its worth
    • [Quinn] In allowing other (Shaped)Types, what constraints does that put on the existing driver/drivers upstream?
      • Would be nice to get rid of SCF’s dependency on tensor, maybe through abstracting to ShapedType
    • [Andrzej] Nobody has spoken up against it strongly - we can go with an RFC which is clear on the problem and the proposed solution. We should also make the charter clearer on this kind of issue.

  • [Jakub] Continue the discussion on updating the Vector dialect docs (remove references to LLVM).

    • Related question: what will the process be related to discussions in this group?
    • [Andrzej] We are figuring it out as we go along. These meetings seem good for pre-feedback before proceeding with the fully public RFCs.

  • [Jakub on behalf of Kunwar] masked load and masked store on vector

    • https://github.com/llvm/llvm-project/pull/131482/
    • Types would not be as explicit any more, i.e. types for masks are dropped
    • What’s the standard that we keep ourselves to
    • [Matthias] Matter of taste as to how much type inference to do
    • [Andrzej] sequence of types lining up with sequence of arguments is generally useful
    • [Jakub] Verifier change makes sense separate from type question
    • [Andrzej] Regarding the types, lets just make sure we are consistent across the dialect, e.g. w.r.t. mask type on all Ops that use masking

  • [Diego] Can we have a vector of !llvm.ptr ?

    • [Jakub] We would need an interface to abstract from the concrete ptr type, otherwise we would have a general dependency on the llvm dialect.
    • [Matthias] Prototype indeed does this
    • [Diego] VectorElementTypeInterface would be too open and generic, can we exercise more control over the types that can be made an element type of vector?
    • [Quinn] How about vector<…xindex>?
    • [Matthias] PtrLikeTypeInterface for allowed vector elements
    • [Quinn] How about serializable types? Would those be okay? How about just those that have a constant bitwidth per element?
    • [Matthias&Diego] Lets do a RFC on just PtrLike elements
    • Nobody is against

  • [Quinn on behalf of Kunwar]

Actions

  • Rolf to post an RFC on “vector tiling”
  • Matthias to post an RFC on “vector of ptrs”
  • Jakub to post an RFC on updating vector dialect docs (reduce references to LLVM LangRef docs)
  • Kunwar to update his PR (split into two - “TableGen update” + “syntax update”). Syntax update to cover all Vector Ops (to maintain consistency).
  • Diego to review Kunwar’s PR.
  • Make sure to go over Andrzej’s PR next time as well :slightly_smiling_face:
2 Likes