[PATCH vkd3d 2/5] vkd3d-shader/hlsl: Perform a copy propagation pass.

Giovanni Mascellani gmascellani at codeweavers.com
Fri Nov 12 04:58:54 CST 2021


Hi,

On 11/11/21 23:11, Matteo Bruni wrote:
>> I think I'm missing something, or have misread part of this, but
>> assuming that we want to go right ahead and split types into vectors
>> where possible, I think it only makes sense to handle vectors in
>> copyprop? If a type is bigger than that and can't be split, I think that
>> means it necessarily has non-uniform access, which means we can't really
>> perform copyprop on it anyway.
>>
>> Or maybe you're already saying exactly that.
> I'm thinking that, although I'm not sure that I said that :D
> But yes, that's how I see things working eventually. There are a few
> missing pieces at the moment and if e.g. we want to go through with
> copy prop right away (which is absolutely fine), we either have to
> handle complex types in copy prop or miss some copy propagation
> opportunities until the other shoe drops. I feel like the latter is
> easier but I'm okay with the former too.

I think my copy propagation patches already handle complex types (i.e., 
handle variables which have complex types; they don't handle loads or 
stores that have complex types, but neither does code generation, so 
there is no loss there), and they don't require jumping through any 
hoops to do that (unless you count dynamically allocating an array as 
jumping through hoops, but I don't think so).

When at some point we'll split variables to simple types, the copy 
propagation pass should keep working just as well, provided that the 
splitting correctly preserve semantics (but that has to happen anyway).

Notice that having a variable with an offset which cannot be known at 
compile time doesn't necessarily mean that copy propagation cannot do 
anything: a variable could have both accesses with statically-known 
offsets and non-statically-known offsets, and the copy propagation pass 
will still use the information it can pinpoint. This might not be the 
common case, sure, but given that nothing has to be done to support it, 
I see no reason to willingly break it.

Giovanni.



More information about the wine-devel mailing list