[mlir] Improve code re-use in VectorEmulateNarrowType.cpp

[banach-space]

Hi folks!

Having reviewed a few recent PRs for VectorEmulateNarrowType.cpp, e.g.:

• [MLIR] Implement emulation of static indexing subbyte type vector stores #115922, or
• [mlir] Rewrites for I2 to I8 signed and unsigned extension #121298,

I believe it’s time to improve code reusability and unify naming conventions in the file. At ~1.7k lines, it's becoming increasingly difficult to review patches.

Proposal 1

To begin with, I would like for us to start re-using the logic from alignedConversionPrecondition. This hook effectively checks two conditions:

1. Per-element alignment (e.g. i2 and i8 are aligned, i3 and i8 are not aligned).
2. Could the input/source vector of sub-byte scalar types (e.g. vector<2xi4>) fit within the target mulit-byte container type (e.g. i8 or i32), this is checked here.

Similar checks are repeated throughout the code, e.g.

• Cond 1: check 1, check 2, check 3 ... .
• Cond 2: check 1, check 2, check 3, ... .

In order to enable re-use, it would help to do some minor variable renaming first. Otherwise, it's quite hard to see that basically identical quantity is computed/defined multiple times throughout the code. Rather than implementing this in one big patch, I have split it into 4 independent changes:

• [mlir][Vector] Update VectorEmulateNarrowType.cpp (1/N) #123526
• [mlir][Vector] Update VectorEmulateNarrowType.cpp (2/N) #123527
• [mlir][Vector] Update VectorEmulateNarrowType.cpp (3/N) #123528
• [mlir][Vector] Refactor VectorEmulateNarrowType.cpp #123529

These are basically stacked PRs. I've made sure to link the relevant commit (1 per PR) in the summary, so that it's easy for you to find it.

Proposal 2

We should clarify the meaning of "source" and "destination" types. Currently, the usage is ambiguous. For example, for this arith.extsi Op,

  %0 = arith.extsi %arg0 : vector<8xi2> to vector<8xi32>

vector<8xi2> and vector<8xi32> are the "source" and "destination" types, respectively (i.e. that's the interpretation we tend to use).

However, patterns like RewriteAlignedSubByteIntExt introduce vector.bitcast Ops like this:

  %bitcast = vector.bitcast %arg0 : vector<8xi2> to vector<2xi8>

I've noticed that we tend to consider both:

• vector<2xi8>(the result of vector.bitcast), and vector<8xi32> (the output of arith.extsi)

as the destination type. That should be clarified. I suggest two steps:

• Avoid "destination" and "source" when referring to the "emulation" logic. Reserve that for the original Op (e.g. arith.extsi above). Better still, use the naming from Op definitions (for arith.extsi that would mean in and out for "source" and "destination").
• For the "emulation" logic, use "emulated type" and "container name" for the original type (to be emulated, e.g. i2) and the target type that's used for emulation (e.g. i8).

WDYT?

Proposal 3

Document the updated naming in the file.

CC @lialan @ziereis @dcaballe

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Andrzej Warzyński (banach-space)

Hi folks!

Having reviewed a few recent PRs for VectorEmulateNarrowType.cpp, e.g.:

• [MLIR] Implement emulation of static indexing subbyte type vector stores #115922, or
• #121298,

I believe it’s time to improve code reusability and unify naming conventions in the file. At ~1.7k lines, it's becoming increasingly difficult to review patches.

Proposal 1

To begin with, I would like for us to start re-using the logic from alignedConversionPrecondition. This hook effectively checks two conditions:

1. Per-element alignment (e.g. i2 and i8 are aligned, i3 and i8 are not aligned).
2. Could the input/source vector of sub-byte scalar types (e.g. vector<2xi4>) fit within the target mulit-byte container type (e.g. i8 or i32), this is checked here.

Similar checks are repeated throughout the code, e.g.

• Cond 1: check 1, check 2, check 3 ... .
• Cond 2: check 1, check 2, check 3, ... .

In order to enable re-use, it would help to do some minor variable renaming first. Otherwise, it's quite hard to see that basically identical quantity is computed/defined multiple times throughout the code. Rather than implementing this in one big patch, I have split it into 4 independent changes:

• [mlir][Vector] Update VectorEmulateNarrowType.cpp (1/N) #123526
• [mlir][Vector] Update VectorEmulateNarrowType.cpp (2/N) #123527
• [mlir][Vector] Update VectorEmulateNarrowType.cpp (3/N) #123528
• [mlir][Vector] Refactor VectorEmulateNarrowType.cpp #123529

These are basically stacked PRs. I've made sure to link the relevant commit (1 per PR) in the summary, so that it's easy for you to find it.

Proposal 2

We should clarify the meaning of "source" and "destination" types. Currently, the usage is ambiguous. For example, for this arith.extsi Op,

  %0 = arith.extsi %arg0 : vector<8xi2> to vector<8xi32>

vector<8xi2> and vector<8xi32> are the "source" and "destination" types, respectively (i.e. that's the interpretation we tend to use).

However, patterns like RewriteAlignedSubByteIntExt introduce vector.bitcast Ops like this:

  %bitcast = vector.bitcast %arg0 : vector<8xi2> to vector<2xi8>

I've noticed that we tend to consider both:

• vector<2xi8>(the result of vector.bitcast), and vector<8xi32> (the output of arith.extsi)

as the destination type. That should be clarified. I suggest two steps:

• Avoid "destination" and "source" when referring to the "emulation" logic. Reserve that for the original Op (e.g. arith.extsi above). Better still, use the naming from Op definitions (for arith.extsi that would mean in and out for "source" and "destination").
• For the "emulation" logic, use "emulated type" and "container name" for the original type (to be emulated, e.g. i2) and the target type that's used for emulation (e.g. i8).

WDYT?

Proposal 3

Document the updated naming in the file.

CC @lialan @ziereis @dcaballe

[dcaballe]

Thanks for bringing this up.

Per-element alignment (e.g. i2 and i8 are aligned, i3 and i8 are not aligned).

Could the input/source vector of sub-byte scalar types (e.g. vector<2xi4>) fit within the target mulit-byte container type (e.g. i8 or i32), this is checked here.

I always thought that the term alignment is misused here. We are checking for the multiplicity/divisibility of the different type sizes. i8 size is a multiple of i2 size, i3 size is not. I think it would be better to use multiple or similar instead of alignment.

For the "emulation" logic, use "emulated type" and "container name" for the original type (to be emulated, e.g. i2) and the target type that's used for emulation (e.g. i8).

Emulated/container or emulated/native types sound good to me. I think we also used "native" somewhere.

[banach-space]

I always thought that the term alignment is misused here.

I am glad that you brought it up. Agreed, I think that it's been a source of a lot of confusion. Lets fix it :)

Emulated/container or emulated/native types sound good to me.

I prefer "emulated/container", lets go with that.

So, mindful that #123526 has already received 3 x "+1" , would you be ok with that patch if I used

• emulatedElemTy + containerElemTy, in place of:
• oldElementType + newElementType

? That would fix consistency and take us back on the right "naming" path :)