On Fri, Nov 19, 2021 at 6:36 PM Zebediah Figura zfigura@codeweavers.com wrote:
On 11/19/21 10:12 AM, Matteo Bruni wrote:
On Fri, Nov 19, 2021 at 4:55 PM Giovanni Mascellani gmascellani@codeweavers.com wrote:
Hi,
On 18/11/21 18:28, Matteo Bruni wrote:
+struct copy_propagation_value +{
- struct hlsl_ir_node *node;
- unsigned int component;
+};
+struct copy_propagation_variable +{
- struct rb_entry entry;
- struct hlsl_ir_var *var;
- struct copy_propagation_value *values;
+};
I still haven't gotten warm to these names. What about copy_propagation_definition (or just copy_propagation_def)?
I don't understand why it's appropriate for this structure, but fine.
It's in the sense of "definition of the current value", more or less like the "def" in use-def chains.
I don't really like this, though, because both copy_propagation_variable and copy_propagation_value are "def"s, but we need some way of disambiguating what's being defined.
Okay, but I don't see how copy_propagation_variable is any better.
I'm fine with whatever, FWIW.
+static struct hlsl_ir_node *copy_propagation_find_replacement(struct copy_propagation_variable *variable,
unsigned int offset, unsigned int count, unsigned int *swizzle)I think I prefer my original suggestion of _get_ (or something else) rather than _find_; the point being that this function isn't really finding anything.
To me it gets something as much as it finds something. I wanted to avoid the word "get" because it seems overly generic, but it's true that "find" is not that much more specific. Ok.
Throwing a couple more options: generate, compute.
I'm... not sure why this function isn't finding something? It's not really generating anything (except a swizzle, I guess); rather it's looking up the stored node that can serve as a replacement.
Although I like "get" too.
Same.