Re: [PATCH, 1/2] Add handle_param parameter to create_variable_info_for_1

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Oct 26, 2015 at 12:22 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> Hi,
>
> this no-functional-changes patch copies the restrict var declaration code
> from intra_create_variable_infos to create_variable_info_for_1.
>
> The code was copied rather than moved, since in fipa-pta mode the varinfo p
> for the parameter t may already exist due to create_function_info_for, in
> which case we're not calling create_variable_info_for_1 to set p, meaning
> the copied code won't get triggered.
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk?

@@ -272,6 +272,9 @@ struct variable_info
   /* True if this field has only restrict qualified pointers.  */
   unsigned int only_restrict_pointers : 1;

+  /* The id of the pointed-to restrict var in case only_restrict_pointers.  */
+  unsigned int restrict_pointed_var;
+
   /* True if this represents a heap var created for a restrict qualified
      pointer.  */
   unsigned int is_restrict_var : 1;
@@ -5608,10 +5611,10 @@ check_for_overlaps (vec<fieldoff_s> fieldstack)


Please don't split the  bitfield like that.  Note that variable_info
is kept as small as
possible because there may be a _lot_ of them.  Is it really necessary to have
this info be persistent?  Why does create_variable_info_for_1 only handle
the single-field case?  That is, I expected this to be handled by c_v_r_f_1
fully.

Richard.





> Thanks,
> - Tom