Apply RLS to @splat builtin, eliminating its length parameter

[antlilja]

Closes #16277

This PR removes the length parameter from the splat builtin instead resolving the result type.

[mlugg]

Sema logic is missing type checks. Need to check dest ty is a vector

[mlugg]

Also, CI failures are because zig1 doesn't have the changes. Run zig build update-zig1 and commit the changes in the stage1 dir (Andrew will recreate this commit before merging for security reasons)

[andrewrk]

Thanks for implementing this.

Hmmmm, looking at the diff, is this change actually good? It seems kind of worse actually. Are there any more opportunities to clean up the diff so that we can see if this change actually results in more maintainable code?

[mlugg]

I think a key thing that would make this nicer to work with is if we can figure out RLS for arithmetic operands, but I'm still unsure what exactly such a proposal would look like

[antlilja]

Thanks for implementing this.

Hmmmm, looking at the diff, is this change actually good? It seems kind of worse actually. Are there any more opportunities to clean up the diff so that we can see if this change actually results in more maintainable code?

I've now pushed some new changes where I cleaned up the code as much as possible.

I do agree that some parts do look a bit less readable. This is the resulting change when the result type cannot be inferred:

// Before:
@splat(N, @as(T, SOME_LITERAL));

// After:
@as(@Vector(N, T), @splat(SOME_LITERAL));

In quite a few places the code is less readable because the type cannot be inferred where it probably could be. I think @mlugg is correct in that RLS for arithmetic operands would help but there are a lot of places where this wouldn't help. For example where this syntax change interacts with the new cast syntax:

// Before:
@splat(len, @as(i32, @intCast(some_var)))

// After:
@as(@Vector(len, i32), @splat(@as(i32, @intCast(some_var))))

[mlugg]

That case can be fixed by adding a result type for @splat's operand using a elem_type_index instruction (or, similarly, by extending elem_type to work with vectors).

[andrewrk]

Thanks for further exploring it with cleanups, @antlilja. Upon reexamination, I think that this change is at worst, neutral. Given that it increases consistency with other builtins, and sometimes can reduce an awkward need to pass the element type rather than the vector type, I'm in favor of moving forward with it.

[antlilja]

Thanks for further exploring it with cleanups, @antlilja. Upon reexamination, I think that this change is at worst, neutral. Given that it increases consistency with other builtins, and sometimes can reduce an awkward need to pass the element type rather than the vector type, I'm in favor of moving forward with it.

Then I'll keep working on it. I've started implementing what mlugg suggested so it works better with the other changes to builtins.