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.