> Hi! > > The following patch removes ipa_bits struct pointer/vector from ipa > jump functions and ipa cp transformations. > > The reason is because the struct uses widest_int to represent > mask/value pair, which in the RFC patches to allow larger precisions > for wide_int/widest_int is GC unfriendly because those types become > non-trivially default constructible/copyable/destructible. > One option would be to use trailing_wide_int for that instead, but > as pointed out by Aldy, irange_storage which we already use under > the hood for ipa_vr when type of parameter is integral or pointer > already stores the mask/value pair because VRP now does the bit cp > as well. > So, this patch just uses m_vr to store both the value range and > the bitmask. There is still separate propagation of the > ipcp_bits_lattice from propagation of the ipcp_vr_lattice, but > when storing we merge the two into the same container. > > I've bootstrapped/regtested a slightly older version of this > patch on x86_64-linux and i686-linux and that version regressed > +FAIL: gcc.dg/ipa/propalign-3.c scan-ipa-dump-not cp "align:" > +FAIL: gcc.dg/ipa/propalign-3.c scan-tree-dump optimized "fail_the_test" > +FAIL: gcc.dg/ipa/propbits-1.c scan-ipa-dump cp "Adjusting mask for param 0 > to 0x7" > +FAIL: gcc.dg/ipa/propbits-2.c scan-ipa-dump cp "Adjusting mask for param 0 > to 0xf" > The last 2 were solely about the earlier patch not actually copying > the if (dump_file) dumping of message that we set some mask for some > parameter (since then added in the @@ -5985,6 +5741,77 @@ hunk). > The first testcase is a test for -fno-ipa-bit-cp disabling bit cp > for alignments. For integral types I'm afraid it is a lost case > when -fno-ipa-bit-cp -fipa-vrp is on when value ranges track bit cp > as well, but for pointer alignments I've added > && opt_for_fn (cs->caller->decl, flag_ipa_bit_cp) > and > && opt_for_fn (node->decl, flag_ipa_bit_cp) > guards such that even just -fno-ipa-bit-cp disables it (alternatively > we could just add -fno-ipa-vrp to propalign-3.c dg-options). > > Ok for trunk if this passes another bootstrap/regtest? > Or defer until it is really needed (when the wide_int/widest_int > changes are about to be committed)?
It does look like a nice cleanup to me. I wonder if you did some compare of the bit information propagated with new code and old code? Theoretically they should be equivalent? Honza
