This is the mail archive of the
mailing list for the GCC project.
Re: types for VR_VARYING
On 8/14/19 8:15 AM, Aldy Hernandez wrote:
> On 8/14/19 9:50 AM, Andrew MacLeod wrote:
>> On 8/13/19 8:39 PM, Aldy Hernandez wrote:
>>> Yes, it was 2X.
>>> I noticed that Richi made some changes to the lattice handling for
>>> VARYING while the discussion was on-going. I missed these, and had
>>> failed to adapt the patch for it. I would appreciate a final review
>>> of the attached patch, especially the vr-values.c changes, which I
>>> have modified to play nice with current trunk.
>>> I also noticed that Andrew's patch was setting num_vr_values to
>>> num_ssa_names + num_ssa_names / 10. I think he meant num_vr_values +
>>> num_vr_values / 10. Please verify the current incantation makes sense.
>> no, I meant num_ssa_names. We are resizing the vector because
>> num_vr_values is out of date (and smaller than num_ssa_names is now),
>> so we need to resize the vector to be at least the number of
>> ssa-names... and I added 10% just in case we arent done adding new ones.
>> if num_vr_values is 100, and we've added 200 ssa-names, num_ssa_names
>> would now be 300. if you resize based on num_vr_values, you could
>> still go off the end of the vector.
> OK, I've changed the resize to allocate 2X as well. So now we'll have:
> + unsigned int old_sz = num_vr_values;
> + num_vr_values = num_ssa_names * 2;
> + vr_value = XRESIZEVEC (value_range *, vr_value, num_vr_values);
> And the original allocation will also be 2X.
I don't think we want the resize to be 2X, we've tried to get away from
those kinds of growth patterns. The 10% from Andrew's patch seems like
a better choice for the resize.