Re: Thoughts on getting correct line numbers in the byte compiler's warning messages

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I timed a bootstrap, unoptimised GCC, with an extra tag check and
> storage to a global variable inserted into XFIXNUM.  (Currently there is
> no such check there).  The slowdown was around 1.3%

That accumulates for every data type, and it increases code size,
reduces cache hit rate...

You may find it acceptable, but I don't, mostly because I know
fundamentally it's not needed: it's only introduced for short/medium
term convenience (to avoid having to rewrite a lot of code).
And I can't see how we'll be able to get rid of it in the long run
(gradually or not).

So in the long run it's a bad option.

> Many of the original forms produced by the reader survive these
> transformations.

Yeah, that's why I thought of using a hash-table.

> I've tried 2., and given up on it: everywhere in the compiler where FORM
> is transformed to NEWFORM, a copy of a hash has to be created for
> NEWFORM.

Same with your new scheme: everywhere where a "big cons-cell" is
transformed, by a macro you'll get a "small cons-cell".
That's a constant of all options, AFAICT.

> Also, there's no convenient key for recording the hash of an
> occurence of a symbol (such as `if').

Ah, right, I keep forgetting this detail.  Yes, that's a major downer.

> 3. is what I'm proposing, I think.

Yes [ sorry, you had to guess; I thought it was clear enough].

> The motivating thing here is that the rest of the system can handle
> NEW-SPECIAL-OBJECT and get the same result it would have from OBJECT.
> Hence the use of Lisp_Type 1, or possibly a new pseudovector type.

How 'bout we don't try to add location to all objects, but only to some
specific objects?  E.g. only cons-cells?

We could add a new "big cons-cell" type which shares the same tag, and
just adds additional info after the end of the normal cons-cell
(cons-cell would either be allocated from small_cons_blocks or
big_cons_blocks, so you'd have to look at the enclosing cons_block to
determine which kind of cons-cell you have).

So normal code is not slowed down at all (except I guess for the GC
which will be marginally slower).


        Stefan