On 11/18/21 12:18 PM, Matteo Bruni wrote:
On Thu, Nov 18, 2021 at 6:43 PM Zebediah Figura (she/her) zfigura@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.