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

Peter Wang novalazy at gmail.com
Tue Feb 17 10:56:57 AEDT 2015


On Mon, 16 Feb 2015 17:54:36 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Mon, 16 Feb 2015 15:56:08 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > > As for non-pregen applications of cross-compilation, I can change
> > > the indexing methods that use bit vectors to use 32 bit words
> > > even on platforms with bigger words, but I don't think that would
> > > solve the bigger problem.
> > 
> > For non-pregen applications of cross-compilation we typically set
> > a bunch of other configure options anyway (see
> > tools/configure_mingw_cross).  One of those options is --bits-per-word.
> > Do the indexing methods that use bit vectors not check the value
> > of that option?
> 
> They do, which is why having the pregen grade component imply
> bits_per_word=32 solves the problem for pregen grades. I was wondering
> whether having cross_compiling imply bits_per_word=32 would be useful,
> since it would not solve the problem illustrated by my example; it would
> merely move the symptom, making it appear in *different* circumstances.

It would also preclude targeting a 64-bit machine from a 32-bit host.

> > --cross-compiling has never implied anything about the number of
> > tag bits.  It's less general than its name would suggest.
> 
> The problem I am pointing out is that the documentation of that option
> does not do anything *other than suggestion*, via a longer rephrasing
> of the option name. It does not say what *specifically* a user is guaranteed
> to be able to do with the output of an invocation of mmc --cross-compiling.

I agree that it is insufficiently documented.

Ideally it would not be necessary.  For current uses, the compiler knows
the host and target word widths so it can disable compile-time
evaluation of builtins dependent on the word-width or, better, emulate
the result that WOULD be obtained on the target.  I think we can do that
now.  There may be other cases in future which are not easily so easily
detected or emulated.

Peter



More information about the developers mailing list