Re: Data Structure Reorganizing Optimizations

ok@cs.rmit.oz.au (Richard A. O'Keefe) writes...
  . . .
> A particularly noteworthy point is that two different structs with the
> same declared fields might be _used_ in different ways, thus warranting
> different arrangements according to (2) and (3). That makes separate
> compilation tricky. I could quite happily sacrifices the existing ordering
> rules of C structs, but I could not sacrifice separate compilation.
> That means that any rearrangements the compiler did *unprompted* should be
> confined to strictly local ones based on the declared types and order of
> the fields, such as type (1).
    . . .


          Makes separate compilation tricky, but not impossible:


One approach might be to use profiling feedback* to make
these decisions - if the compiler had access to info on
data access patterns, it could make the same decision
when compiling each module.


Another possibility is to have an integrated development
environment that carries descriptive information that can
be used when compiling modules that aren't the first to
reference a given structure.


In both cases, one might not expect very good results on the 1st
compilation (with improving results on later compilations), but there's
no reason the 1st pass results would be any worse than current compilers
(and in the second case, some reason they might be better).


          Separate compilation doesn't have to mean having no information on
the other modules being compiled.


*see ftp://ftp.fwi.uva.nl/pub/functional/icos_project.ps.Z for an
  interesting paper that touches on the value of profiling feedback
  in optimization.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.