On 9/9/19 4:33 PM, Jan Hubicka wrote: >> PING^1 >> >> On 8/26/19 12:04 PM, Martin Liška wrote: >>> Ok. I have a semi-working patch that has issues for inline clones. >>> When we call cgraph_node::get_untransformed_body for an inline clone, >>> then one needs to use clone_of->order to find proper LTO stream. > > This seems OK to me - when using inline clone we really look for a body > of its master, so that seems OK.
Ok! >>> >>> What's more problematic is that such clone can be expanded: >>> >>> f/12 (f) @0x7ffff769f708 >>> Type: function definition analyzed >>> Visibility: external public >>> References: mumble.lto_priv.0/8 (write) >>> Referring: >>> Read from file: /tmp/cciAkXHp.ltrans1.o >>> Function f/12 is inline copy in main/0 >>> Availability: local >>> Function flags: count:1073741824 (estimated locally) local nonfreeing_fn >>> executed_once >>> Called by: main/0 (inlined) (1073741824 (estimated locally),1.00 per >>> call) >>> Calls: >>> >>> and lost. So we end up with an orphan and we ICE with: > > We do some work on removing unnecesary master clone when function is > fully inlined and I guess in that case you lose the order info. > One option would be to copy order into all inline clones (it does not > have very good meaning there) or do that when reshaping the tree. What do you mean by "reshaping the tree"? > This is done in cgraph_node::remove at the place clone_of is > manipulated. The inline_clone manipulation happens in cgraph_node::find_replacement where we manipulate the clone_of. Martin > This is probably bit cleaner. >>> >>> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c: In >>> function ‘main’: >>> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/lto/20081112_0.c:10:3: >>> fatal error: /tmp/cciAkXHp.ltrans1.o: section f is missing >>> >>> So usage of symtab_node::order seems awkward to me :/ >>> >>> Martin >>> >>
