typedef fileline location_t

[Per Bothner]

I did a small timing experiment, bootstrapping with
--disable-checking --enable-languages=c.  The numbers
aren't fully meaningful, because I'm compiling different
codes (without and with the patch).  Also, a good chunk
of the time is spent in stage1 or otherwise where there
wouldn't be any difference.  So, for what it's worth:

mainline:
   real 22m40.075s;  user 20m42.340s;  sys   0m58.490s
with patch to replace location_t by fileline:
   real 22m11.633s;  user 20m40.450s;  sys   0m59.580s
similar, but cache most recent liemap_lookup result:
   real 22m12.009s;  user 20m41.210s;  sys   0m58.970s

All results on an unloaded Athlon 2600+ running a beta of
Fedora Core.  I don't know why the relatively large
disparity in real times while user and sys times are
so close; perhaps some cron task woke up ...

The change looks like it *might* be a speed improvement,
but the numbers are inconclusive.  It may be worthwhile
porting the patch to the tree-ssa branch.  However, I'd
like some more feedback on the patch before I go to that
effort.  For example, is there consensus on the typename
'source_location'?

I've included the revised patch.  The main difference is
the line-map cache, which is local to line-map.h and line-map.c.
(That could probably go in separately.)

My feeling is that this is a conceptual unification and
code simplification, so it should go in unless there is
an actual compile-speed regression, which there doesn't
appear to be.  And it will also be highly desirable for
the compile-server branch, since otherwise I will have to
add an extra field in each decl.  Unless we can get more
a definite speed-up, it may be a little late for 3.4
(especially as other back-ends aren't done yet), though I'd
argue for it going into the tree-ssa and compile-server
branches (when the other front-ends have been converted),
as well as any possible 'basic-improvements' branch.
On the other hand, having this in 3.4 may simplify future
merges.  I guess it will depend on how much of a speed
improvement there is, if any, and how quickly we can
convert the other front-ends.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: location.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20031021/f5e6e6c6/attachment.ksh>