On Thu, Sep 3, 2026 at 9:24 AM Robin Dapp <[email protected]> wrote: > > > Oh, I was looking for a rationale for the restriction to constant-ness > > (and specifically - off my head, without rechecking the patch - data > > structure limitations from that decision). So yes, we can restrict > > to constants, but can we keep the infrastructure in a way that we > > _could_ allow non-constants? Like maybe SSA default defs > > (parameter values)? > > Thought about this for some time and while it wouldn't be too much work > to fit in non-constant factors, I'm not sure it's really worth it. > What I'd really like to avoid is (a + b) * (c + d), so maybe we should > keep the non-constant factors as SSA names and not descend into them. > > The hash_map would would need pair<constant, SSA name> as key or > similar, that's doable. Costing is another matter but as long as we > reject the transform when there are more multiplications than before, I > suppose we're still good. So the current shape is not fully unsuitable > (it's not that much code anyway) and we could add variable-factor > handling, but I'd rather not :) If necessary, I'd not go deeper than > one level as said above.
OK, I will see to go over the series in detail and think about the above when doing so. Hopefully soon ... Richard. > > -- > Regards > Robin >
