<whitequark[cis]>
jix: so, consider the case of duplicating a flop without an initial value
<whitequark[cis]>
under the model you propose that's not legal, meaning that let's say for an ASIC target, we can never duplicate flops
<whitequark[cis]>
(i suppose on FPGAs you could have some metadata saying "this and that flop actually must be initialized the same", which is a massive pain but technically workable. on ASICs i don't think it is?)
<_whitenotifier-4>
[prjunnamed/vscode-syntax] whitequark 03dcdbf - Add memory port related keywords.
<whitequark[cis]>
there's another big issue here
<whitequark[cis]>
consider actually using the undef cell for optimization
<whitequark[cis]>
1) whenever an optimization makes use of it to assume a certain value, it has to RAUW the `undef` with that constant. but this suddenly makes pass ordering an *even worse* issue, one that is completely undebuggable by anyone but the toolchain author
<whitequark[cis]>
2. even without pass interactions, consider that a single pass assuming that `undef` is either 1 or 0 can have a major effect on resource usage. sure, we'll need to have some cost function, and hopefully it's a good one, but there can and will be cases where a decision made locally affects global resource use in a way that's problematic. this is also undebuggable
<whitequark[cis]>
for all its faults, X propagation has the benefit that it's order-independent and that you only do it to delete logic
<whitequark[cis]>
(the monotonicity requirement of simplify convergence)
<whitequark[cis]>
in practice i suspect it will degenerate into "assume X is 0" quickly, at which point you might as well not have it in first place and just manually use whichever value gives you fewer LUTs in any particular place instead of placing an X there, like you have to do in Amaranth today