> 2010/4/29 Jan Hubicka <hubi...@ucw.cz>: > >> Well, we'd then need to re-architect the symbol merging and > >> LTO unit read-in to properly honor linking semantics (drop > >> a LTO unit from an archive if it doesn't resolve any unresolved > >> symbols). I don't know how easy that will be, but it shouldn't > >> be impossible at least. > > > > We also should keep in mind that we really ought to be able to produce LTO > > .o files > > without actual assembly in, so either we should not tie this too much with > > linking > > process anyway or we need to output fake symbols into the LTO .o file when > > assembly > > is not done. > > (I guess one can just output empty variables and functions, but then .o > > will link > > without LTO and lead to wrong code). > > > > This is IMO quite important feature, we don't want to double compile times > > forever. > > Well, what we should do anyway is short-cut compilation after > LTO bytecode output and go directly to expansion. Otherwise > we risk to have different sets of symbols with the intermediate > object files and thus symbol resultion with GOLD does not > work compeltely (there are bugs about this already). > > So compile-time wouldn't be _that_ bad (just RTL opts and > assembling).
Well, but in that case the resulting assembly would be completely useless anyway. RTL opts and expansion play important factor, so it would be nice to avoid those. Honza
