On 8/12/19 12:43 PM, Aldy Hernandez wrote:
> This is a fresh re-post of:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00006.html
>
> Andrew gave me some feedback a week ago, and I obviously don't remember
> what it was because I was about to leave on PTO. However, I do remember
> I addressed his concerns before getting drunk on rum in tropical islands.
FWIW found a great coffee infused rum while in Kauai last week. I'm not
a coffee fan, but it was wonderful. The one bottle we brought back
isn't going to last until Cauldron and I don't think I can get a special
order filled before I leave :(
Their more traditional rums were good as well. Koloa Rum. See if you
can get it locally :-)
>
> This patch adds MIN/MAX values for VR_VARYING. As was discussed
> earlier, we are only changing VR_VARYING, not VR_UNDEFINED as was the
> original plan.
>
> As I mentioned earlier, I am tired of re-doing ChangeLogs, so I'll whip
> up the changelog when the review starts.
ACK.
> @@ -150,12 +166,11 @@ vr_values::set_defs_to_varying (gimple *stmt)
> ssa_op_iter i;
> tree def;
> FOR_EACH_SSA_TREE_OPERAND (def, stmt, i, SSA_OP_DEF)
> - {
> - value_range *vr = get_value_range (def);
> - /* Avoid writing to vr_const_varying get_value_range may return. */
> - if (!vr->varying_p ())
> - vr->set_varying ();
> - }
> + if (value_range_base::supports_type_p (TREE_TYPE (def)))
> + {
> + value_range *vr = get_value_range (def);
> + vr->set_varying (TREE_TYPE (def));
> + }
> }
Is the supports_type_p stuff there to placate the calls from ipa-cp? I
can live with it in the short term, but it really feels like there
should be something in the ipa-cp client that avoids this silliness.
>
> /* Update the value range and equivalence set for variable VAR to
> @@ -1920,7 +1935,7 @@ vr_values::dump_all_value_ranges (FILE *file)
> vr_values::vr_values () : vrp_value_range_pool ("Tree VRP value ranges")
> {
> values_propagated = false;
> - num_vr_values = num_ssa_names;
> + num_vr_values = num_ssa_names + num_ssa_names / 10;
> vr_value = XCNEWVEC (value_range *, num_vr_values);
> vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
> bitmap_obstack_initialize (&vrp_equiv_obstack);
My recollection was someone (Richi) proposed 2X for the initial
allocation which should ensure that in all but the most pathological
cases that we never trigger a reallocation. In terms of "wasted" space,
it shouldn't matter in practice.
So if you could check the old thread and verify that Richi recommended
the 2X initial allocation and if so, make that minor update.
Jeff
