Add LL::quotient and remove uses of divideRight and sublayoutIsIdentity

[lezcano]

We add a new abstraction LL::quotient that abstracts the idea of "a
linear layout does not permute certain dimensions". Doing so, allows us
to remove divideRight and subsume them into this higher-level abstraction.
We also fix a bug in isCrossCTAConversion.

We also remove some code duplication from transferWithinThreads and
cvtReorderRegisters in favour of a more generic approach.

We fix a bug in sublayout that meant that sublayout would reorder outDims
at will by using a set instead of a vector.

I am missing adding tests for LL::quotient, will do in a minute.

[Jokeren]

May I know what bug is there?

We also fix a bug in isCrossCTAConversion.

[Jokeren]

I think the function is like a special implementation of divideRight, but the function name itself sounds like a general implementation. It's not general enough though to get a quotient in all circumstances because it requires the linear map to be the identity.

Maybe you can consider changing the function name

[lezcano]

This is intentionally less general than divideRight. My point here is that I don't think that we ever need anything as general as divideRight. divideRight tries to find a left-inverse (right-inverse?) to the tensor product. This is way too powerful and reasonably tricky to do in general (doesn't exist for an arbitrary tensor, it has to be surjective and preserve the tensor product structure).

quotient is simpler (easier to check that its implementation is correct in all cases) and more difficult to use wrong, so I argue it's the right abstraction we want here.

[Jokeren]

So my point here is that we should probably change the function name as it's not strictly speaking a quotient. IMO it's better to denote it in the function name rather than looking up the comment

[lezcano]

It is a quotient in the sense of vector spaces. It's only that's not as general as the quotient there, as a linear function descends to a function on the quotient if it maps the space that you are quotienting by into itself. Here we are a bit tighter, as we ask for it to also be the identity in this subspace, but I think it's alright?

[lezcano]

In case you are not familiar with the quotient of vector spaces, just note that that wiki page is the best resource to learn about them as it's a bit too terse. I can find a better explanation somewhere else tomorrow (closing this for today). (if you know about that concept then disregard this message :D)

[Jokeren]

It's only that's not as general as the quotient there, as a linear function descends to a function on the quotient if it maps the space that you are quotienting by into itself.

Right, that's what I meant

[Jokeren]

In case you are not familiar with the quotient of vector spaces

Nope, I'm not. I'll take a look

[lezcano]

sorry, I miswrote above "it's the best resource" when I meant "it's not the best resource" lol

[lezcano]

Perhaps a better name for this function would be isTrivialOver, as it checks whether it acts trivially (as the identity map) on a given set of dimensions... I think that quotient is a good name for the other function, where we quotient over a set of variables, even if we give up in some cases where you could actually quotient, so I think it's fine to leave it as a NYI comment. Thoughts?

[Jokeren]

Same as above. Because I think it's a special case for divideRight.

[Jokeren]

So, are we ignoring the case where the input dimension names are not equal to the output dimension names, but the input and output are identity mappings?

[lezcano]

The identity in maths is just defined between a space and itself, so yes, this is the correct mathematical concept. Even if you have registers that map 1-to-1 to a vector of outputs, this would not be an identity map strictly speaking, as it's not mapping elements to themselves, but identifying registers with a matrix.

[Jokeren]

OK, makes sense then

[lezcano]

May I know what bug is there?

Previously, we were checking that:

return !layout.sublayoutIsZero(nonBlockInDims.getArrayRef(), {kBlock}) ||
         !layout.sublayoutIsIdentity({kBlock}, {kBlock});

This means that the kBlock of the output will be defined uninquely and as the identity by the kBlock of the input, which is fine. But we are missing a check that layout.sublayoutIsZero({kBlock}, nonBlockOutDims.getArrayRef()), as otherwise the layout will depend on the kBlock, but a few lines after that we are "removing" the kBlock dimensions, effectively assuming that that sublayout is zero.

At the moment I have drawn this rather rough distribution, but it can be optimised in the future. For example, if you just have those two initial conditions, you can still perform the conversion without using distributed shmem, but you'll need to write an indexing that depends on kBlock, which is a tad trickier, but of course, can be done.

[Jokeren]

This means that the kBlock of the output will be defined uninquely and as the identity by the kBlock of the input, which is fine. But we are missing a check that layout.sublayoutIsZero({kBlock}, nonBlockOutDims.getArrayRef()), as otherwise the layout will depend on the kBlock, but a few lines after that we are "removing" the kBlock dimensions, effectively assuming that that sublayout is zero.

Sure, I think it makes sense