[m-dev.] MSVC and --no-smart-indexing

[Paul Bone]

When we disable smart indexing Mercury can generate long chains of
if-then-else code.  In hlc grades it looks like this:

    if (...) {
        ...
    } else {
        if (...) {
            ...
        }
        else {
            ...
        }
    }

This can cause MSVC 2010 to overflow it's stack, for example when compiling
the very big switch in options.m's long_options predicate.  This is a
problem because now we cannot install from the source distribution (which is
compiled with --no-smart-indexing) with MSVC 2010.  (I don't know if this
affects other versions of MSVC).

We disabled smart indexing for the source distribution after a problem was
discovered the with the computed goto code on low level backends:

    http://www.mercurylang.org/list-archives/users/2010-June/005155.html
    https://www.mercurylang.org/bugs/view.php?id=115

At the time we suspected that some code generation doesn't understand that
the target only has 32 bits per word while the host has 64 bits per word.
We could either fix this directly or re-enable smart indexing but cause
--cross-compiling to disable computed gotos.

After searching ml_switch_gen.m and other files it doesn't appear if
computed gotos are used at all in the high level backends.  This seems
strange so maybe I've made a mistake, but if I haven't then we could safely
re-enable smart indexing, which would avoid my problem with MSVC.  Ideally
of course we could generate correctly cross-compiled computed goto code.  Am
I correct?  Can anyone think of any other problems with re-enabling smart
indexing for the source distribution?

Slightly off-topic but there is perhaps a better way to generate code for
large string switches.  A string switch could be decomposed into a nested
series of switches on each character (like a radix-search).  Of course this
could also generate very large amounts of code which might cause different
issues for C compilers.  Also has gperf been considered, either directly or
by re-implementing it's algorithms in Mercury?

Cheers.

-- 
Paul Bone