opt_lut: Narrow LUTs with constant inputs

[povik]

No description provided.

[povik]

This doesn't respect the dlogic flag.

    -dlogic <type>:<cell-port>=<LUT-input>[:<cell-port>=<LUT-input>...]
        preserve connections to dedicated logic cell <type> that has ports
        <cell-port> connected to LUT inputs <LUT-input>. this includes
        the case where both LUT and dedicated logic input are connected to
        the same constant.

Is this flag something we want to preserve?

[povik]

Maybe this should go to opt_expr

[Ravenslofty]

Is this flag something we want to preserve?

Yes, because of how iCE40's weird carry chain works: SB_CARRY is before the LUT, rather than after it.

[povik]

But please tell me the part that says "this includes the case where both LUT and dedicated logic input are connected to the same constant." is an artifact of how the pass was written and should be fixed, rather than something of importance somewhere.

[Ravenslofty]

I think the fact that the iCE40 add_sub test fails suggests that yes that is a load-bearing requirement, but let me ask around.

[whitequark]

I wrote the pass. The reason opt_lut exists is mostly an alternate no-abc flow, though it has since gained some additional load to bear. I think -dlogic is a weird way to do what it does and it should have -tech ice40 or something like that instead, but the function should probably be preserved, considering otherwise you basically cannot run it on iCE40 without violating all the constraints for carry chain insertion.

[povik]

The reason opt_lut exists is mostly an alternate no-abc flow

Well then it's no surprise it has come up again in relation to toymap. Would there be objections to replacing -dlogic with -tech ice40 now?

[whitequark]

Would there be objections to replacing -dlogic with -tech ice40 now?

Absolutely none; in fact this is how it should've been done in first place and -dlogic was a poor technical decision owing to immaturity on my part.