Scalable vectors can’t occur as global variable initializers, so at least that part of the equation doesn’t change, right? IRBuilder already has a CreateVectorSplat method which is a good first step.
From a quick glance, it seems that the worst pain point may be that Constant::getIntegerValue and even ConstantInt::get and friends can be applied to vector-of-int types to produce splats. If we want to get rid of those constant expressions (and I lean towards “yes”), it looks like an important first step would be to dig into the fall-out of removing those code paths.
Well I guess this is convenient based on how the code used to work, now it should loop over all the users and insert corresponding instructions I think?
I’m happy to see constantexpr go away and appreciate this effort, could we introduce a new kind of splat constant to support this case? Being forced to use instructions could be a problem for scalable vectors. Consider that these instructions could be hoisted out of a loop by LICM, where it would be preferable to observe the constant in the expression that used it (think of add immediates, for example).
I really like that idea. At least conceptually, this makes a lot of sense to me and should help ensure that scalars and vector splats receive consistent handling, because they really should. In practice, I’d expect this will break assumptions people have been making, e.g. because constants get recreated with scalar types.
How would we spell such a constant in IR? At least the scalable vector case would need some dedicated syntax.
As I understand it, bitcast and addrspacecast would have quite different semantics in that case – is it true that we would never need the addrspacecast semantics in global initializers?
Is that no-op only invariant enforced anywhere? I ask because in my address space 7 lowering PR, I could write tests involving addrspacecast ptr addrspace(8) [const] to ptr addrspace(7) … which is a shift left (and has to be some sort of transformation, since the pointers are of different sizes), not a noop.