[PATCH vkd3d v7 4/6] vkd3d-shader/hlsl: Perform a copy propagation pass.

[Zebediah Figura]

On 11/18/21 12:18 PM, Matteo Bruni wrote:
> On Thu, Nov 18, 2021 at 6:43 PM Zebediah Figura (she/her)
> <zfigura at codeweavers.com> wrote:
>>
>> On 11/18/21 11:28, Matteo Bruni wrote:
>>> This and copy_propagation_transform_block() are a bit of a
>>> reimplementation of transform_ir(). It should be possible to extend
>>> transform_ir() to handle this new pass instead.
>>>
>>> I'd introduce a struct like
>>>
>>> struct transform_pass
>>> {
>>>       bool (*initialize)(struct hlsl_ctx *hlsl_ctx, void **ctx);
>>>       bool (*process_instruction)(void *ctx, struct hlsl_ir_node *, void *);
>>>       void (*destroy)(void *ctx);
>>> };
>>>
>>> and update transform_ir() and the existing passes to make use of it. I
>>> imagine we could have some generic initialize() implementation simply
>>> doing *ctx = hlsl_ctx; and an empty destroy() implementation to be
>>> used when there is no particular context to carry around (like in the
>>> existing passes).
>>>
>>
>> Pretty much the whole point of transform_ir() is that it recursively
>> iterates through CF blocks for cases where you don't care about
>> transforming the CF blocks themselves. That's not the case here. What
>> you're describing sounds to me like a framework that doesn't actually
>> serve any purpose to its use case.
> 
> Well, transform_ir() could start calling process_instruction() for the
> HLSL_IR_IF and HLSL_IR_LOOP instructions before recursing, allowing
> the pass to do what it needs for those, and existing passes would keep
> ignoring those instructions. Would that not be enough? Or are you
> saying that transform_ir() should not become more complex?
> 

It could, but we also need to do things after the else/loop block, and 
between the if and else blocks. At that point, as far as I see it, the 
copy propagation function has to manually handle enough logic that 
transform_ir() doesn't actually save us any work.