[PATCH vkd3d v2 10/10] vkd3d-shader/hlsl: Lower numeric casts.

Giovanni Mascellani gmascellani at codeweavers.com
Tue May 17 08:21:05 CDT 2022


Hi,

Il 16/05/22 19:42, Zebediah Figura ha scritto:
>> 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.

Whatever number they are, it is at least a few places versus just one 
well-defined place. Also, in the latter case the place is always the 
same (it would be one of the first optimization passes), while in the 
former case the places where you need to take care of this might change 
with time, further complicating a piece of code (the front end) which is 
already rather involved in itself. The optimization passes have a much 
nicer structure, it's just a pipeline for which hlsl_emit_bytecode() 
gives a quick and readable summary.

>> 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.

If the first few passes care about ensuring the invariants that we want 
in later "real" passes then we get both the advantages of having a 
simpler IR (except in the first few stages, but that's doesn't look like 
a huge drawback) and giving an easier-to-read structure to the compiler 
without overloading the front end.

But I already tried to convince you and Matteo of this and I didn't 
manage, so I guess I'll withdraw.

Giovanni.



More information about the wine-devel mailing list