On 14 November 2014 00:44, Jan Hubicka <hubi...@ucw.cz> wrote: >> Honza, >> >> On 23 June 2014 06:24, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> > --- lto-cgraph.c (revision 211881) >> > +++ lto-cgraph.c (working copy) >> > @@ -614,6 +614,7 @@ lto_output_varpool_node (struct lto_simp >> > /* in_other_partition. */ >> > } >> > bp_pack_value (&bp, node->tls_model, 3); >> > + bp_pack_value (&bp, node->used_by_single_function, 1); >> > streamer_write_bitpack (&bp); >> > >> > group = node->get_comdat_group (); >> > @@ -1275,6 +1276,7 @@ input_varpool_node (struct lto_file_decl >> > if (node->alias && !node->analyzed && node->weakref) >> > node->alias_target = get_alias_symbol (node->decl); >> > node->tls_model = (enum tls_model)bp_unpack_value (&bp, 3); >> > + node->used_by_single_function = (enum tls_model)bp_unpack_value (&bp, >> > 1); >> > group = read_identifier (ib); >> >> Let's please remove the (wrong) cast to tls_model for the >> used_by_single_function bit. > > Yep, it is obiovus pasto :) > >> PS: lto-cgraph should seemingly be switched to use bp_unpack_enum(), no? > > Yes, in genral lto-cgraph needs a lot of cleanups (most of that code was > written in early LTO days and needs a rewrite, it just never broke badly > enough > to force it), I will try to schedule these early next stage 1. > >> PPS: input_ref() speculative setting should also remove the wrong enum >> ipa_ref_use cast. >> I better stop reading here ;) > Hehe, just go ahead and keep me posted ;)
lto_output_node does not really like bp_pack_enum (&bp, node_frequency, 2+1, node->frequency); though. I'll try to have a look in the evening. btw, i've seen that struct symtab_node has two huge gaps, 30bit and 4bytes [initially meant to play around with a simple pahole-like plugin to point those out]. So i started to play around in layout_struct to automatically reorder member elts to fill eventual gaps, just to see how/if offsetof and addressof and ada break if i put a 2D packing step there. But that raises the question if we have hit-rate data, perhaps in profile-mode?, for struct member-access yet? Would be nice to be able to weight the hotter members higher, towards the start of the struct. Even neglecting ABI concerns, I fear this obvious idea is a bit more time-consuming than i'd like it to be..
