On 11/16/20 12:20 AM, Jan Hubicka wrote:
This is controlled by -fipa-icf-alias-sets
The patch drops too early, so we may end up processing function twice. Also if
merging is not performed we lose code quality for no win (this is rare case).
My original plan was to remember the mismatched parameter and apply them only
after merging decisions are finished, but I was not sure how to do that in
ipa-icf. In particular we need to ensure transitivity. In particular if
function foo is merged to bar, we also need to be sure that we dropped
base alias setsin functions tht are called by bar even if they themselves
are not merged. Martin, is there easy way to implement this on top of current
ICF?
Well, you will need to create a set of merged functions and then traverse all
callers of these (via cgraph_node callers). It should not be so difficult, or?
Patch improves ICF code size savings on cc1plus to 1.3% compared to 0.6% before
patch
and 3% with -fno-strict-aliasing. 6802 functions are merged and 3975 base alias
sets
are dropped, 3642 originating from hash-table.h.
memory stats are:
ipa lto gimple in : 1.01 ( 3%) 0.47 ( 12%) 1.56 (
4%) 228M ( 14%)
tree operand scan : 0.40 ( 1%) 0.16 ( 4%) 0.49 (
1%) 39M ( 2%)
ipa icf : 1.96 ( 6%) 0.20 ( 5%) 2.14 (
6%) 12M ( 1%)
TOTAL : 31.99 3.99 36.07
1632M
compared to --disable-ipa-icf:
TOTAL : 26.52 2.44 29.21
1354M
To recover more of -fno-strict-alias-analysis we could have
-fipa-icf-alias-sets 4-state
-fipa-icf-alias-sets=0 do not drop any TBAA
-fipa-icf-alias-sets=1 drop base alias sets
-fipa-icf-alias-sets=2 drop pointer ref alias sets
-fipa-icf-alias-sets=3 also drop ref alias sets to 0 for completely
incompatible types.
On GCC most common reason is now diference in pointer types. so =2
should get the 3% of code size.
Bootstrapped/regtested x86_64-linux.
OK for mainline? I would be also fine with making this wait for next
stage1 if that looks too intrusive (with part 3 of series at least icf
is not consuming a lot of memory for nothing), but there ought to be
again very nice savings on libreoffice which I think had double-digit
saving for icf (13% if I recall correctly). I am busy tomorrow but will
start looking into firefox, clang and libreoffice builds again on
wednesday.
I would recommend deferring that to the next stage1.
Thanks for working on that Honza,
Martin
