[m-dev.] for review: constraint propagation

[Simon Taylor]

Fergus wrote:
> A few general comments:
> 
>  -	Constraint propagation might not preserve unique-mode-correctness.
> 	Do you check to ensure that unique-mode-correctness is preserved?

Could you give an example of a case where constraint propagation
might not preserve unique-mode-correctness?

>  - Constraint propagation might also not preserve determinism-correctness.
>     	You need to be careful not to move constraints before calls to
> 	cc_nondet or cc_multi procedures.  Do you do that?

If there are constraints after a call, the call can't be in a single
solution context, so the called procedure can't have determinism
cc_nondet or cc_multi. Constraints are not pushed into goals with no
output variables.

I will add a check for this case to pd_util__can_reorder_goals.

>  -	Constraint propagation should be disabled if `--no-reorder-conj'
> 	is set.

OK.
 
> Does the compiler bootstrap and pass its tests
> with constraint propagation enabled?

It does.

> If so, then you should enable constraint propagation
> at one of the `-O' levels, e.g. -O3 or -O4.

I'd rather not. While the optimization has little effect on the
code size of the compiler, I don't think it is controlled well
enough to be applied to arbitrary programs.
 
> Also, it would be nice to know if constraint propagation
> has any effects on the compiler's size and speed

-rwxr-xr-x   1 stayl    mercury  7389184 Feb 28 19:30 compiler/mercury_compile
-rwxr-xr-x   1 stayl    mercury  7585792 Feb 27 20:35 stage2/compiler/mercury_compile

No real difference in speed.
 
> Here you propagate the constraints into all the disjuncts in a disjunction.
> That might increase code size, so it bears thinking about.
> What's the worst-case scenario?
> Would there be cases where enabling constraint propagation
> will end up increasing code size with no benefit?

Yes. In practice, I don't think it will be much worse than follow_code.

> If so, is there anything we can do to avoid such cases?

Not really.
 
Simon.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------