Some compiler rewrites marked "safe" are really unsafe

[sjamaan]

Due to a currently unknown reason, sometimes the scrutinizer seems to be able to prevent hardwired compiler rewrites from being done.

If the following code is interpreted, it will print two lines saying "error". If it is compiled, it will either print "error" and "smaller", or in case of a DEBUGBUILD, it will print "error" and show a low-level type assertion error.

(use ports)
(handle-exceptions exn
    (print 'error)
    (print (if (char<? 1 #\a) 'smaller 'bigger-or-equal) ))
(handle-exceptions exn
    (print 'error)
    (print (if (char<? (with-input-from-string "1" read) #\a)
               'smaller 'bigger-or-equal)))

Perhaps it's a good idea to remove the compiler rewrites completely (they are in c-platform.scm), and, where suitable, move the rewrites to types.db. This will prevent bogus rewrites like the one above, and should also make the compiler simpler. We must ensure this doesn't mess up performance too bad. Benchmarking will help.

[sjamaan]

See also #1216; it shows that this bug is more serious than previously thought

[sjamaan]

OK, the "unknown reason" is now known: The topmost call won't get replaced due to attempted constant-folding via constant-form-eval, which fails (due to the exception), and therefore added to the broken-constant-nodes list.

These broken constant nodes are exempt from simplification in optimizer.scm, right at the top of walk in perform-high-level-optimizations. This is unrelated to #1216, I think.

[sjamaan]

Fixed with 379a019 / 274e7af