On 5/16/22 09:58, Giovanni Mascellani wrote:
Hi,
Il 13/05/22 01:18, Zebediah Figura ha scritto:
I don't think this feels like the right place. Can we handle this when parsing explicit casts instead?
Hm, this is useful in many places beside explicit casts. Actually, most tests fixed by this commit are not explicit casts.
Eh, explicit or implicit, sorry. You can't implicitly cast scalars to structs or arrays (at least not in the places I checked) but I forgot that you can cast them to matrices.
In principle we could do the same processing each time we add any cast, explicit or not, but that means we have to hook in many places, making everything more brittle.
Would it be many places, though? I think it'd only be the explicit cast parsing rule and add_implicit_conversion(). We'd want a helper function anyway, that wraps hlsl_new_cast() and handles scalar-to-structure casts.
What's the problem with having this as an optimization pass? Why is that different from lower_broadcasts()?
Broadly, it's the principle of making the IR as simple as possible. In this case it's especially helpful to be able to assume that types larger than a vector can only be generated by HLSL_IR_LOAD instructions. But I think it'd also be desirable to handle scalar-to-vector broadcasts at parse time; I just didn't consider that when writing the pass.
[This certainly isn't the only place where we can generate instructions with matrix type. Most notably they can also come from per-component arithmetic instructions. But I suspect the answer is that we want to lower those at parse time as well; I think it shouldn't be too painful since we can do it in add_expr() or something close to it.]