This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: types for VR_VARYING




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);
etc

And the original allocation will also be 2X.

Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]