Re: integral location_t

[Nathan Sidwell <nathan at codesourcery dot com>]

Richard Henderson wrote:
> Would those that are interested in this representational change
> let me know what requirements they were thinking of from a 
> library or interface perspective?
>
> On tree-ssa branch we're currently storing location_t* in 
> expressions, trying to save space. 
Oh, wow, when I calculated the space needed (on mainline), I
decided there was insufficient location_t reuse. I presume tree-ssa
has many more location_t's.

> I'm now thinking that we 
> might just want to go ahead with the change to integers and
> lookup tables.
yay! I'm sorry that I was unable to complete that transition, due
to other commitments. I'm not sure how this will interact with
the multiple-translation unit mode -- we'll still need globally
unique line-id's. IMHO, the following is needed

*) globally unique line-ids -- no context is needed for the
line-id -> file:line mapping
*) ability to obtain a line-id corresponding to filename without line
number (whether this maps directly from line-id -> line_id or from
filename to line-id, I'm not sure, I suspect the former might be better).
*) ability to create new line-id's 'off the end' of the main input file(s)
(so artificial functions such as static_initialization..., have unique
line numbers)
*) the ability to map a line-id to a translation unit might already be
needed for the multiple-translation unit mode, and probably would be when
C++'s export is implemented

Obviously NOTE rtl can store the line-id in the NOTE_DATA, and
NOTE_LINE_NUMBER becomes merely NOTE_TYPE. (We could even shrink the notes,
by splitting the NOTE code itself into the various note kinds, and thereby
remove the NOTE_TYPE field.)

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
         The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk