On 03/11/15 16:08, Richard Biener wrote:
> On Tue, 3 Nov 2015, Tom de Vries wrote:
>
>> On 01/11/15 19:20, Tom de Vries wrote:
>>> On 01/11/15 19:03, Tom de Vries wrote:
>>>> So, the new patch series is:
>>>>
>>>>        1    Rename make_restrict_var_constraints to make_param_constraints
>>>>        2    Handle recursive restrict in function parameter
>>>>
>>>> I'll repost in reply to this message.
>>>>
>>>
>>> This patch adds handling of all the restrict qualifiers in the type of a
>>> function parameter.
>>>
>>
>> And reposting an updated version, now that the toplevel parameter in
>> make_param_constraints has been eliminated.
>
> @@ -5195,6 +5197,8 @@ struct fieldoff
>     unsigned may_have_pointers : 1;
>
>     unsigned only_restrict_pointers : 1;
> +
> +  varinfo_t restrict_var;
>   };
>
> store the varinfo ID here, 'unsigned int restrict_var' which ends
> up not changing fieldoff size.  get_varinfo (restrict_var) will get
> you the varinfo_t.

Done, attached.

>
> @@ -5374,6 +5380,19 @@ push_fields_onto_fieldstack (tree type,
> vec<fieldoff_s> *fieldstack,
>                    = (!has_unknown_size
>                       && POINTER_TYPE_P (field_type)
>                       && TYPE_RESTRICT (field_type));
> +               if (handle_param
> +                   && e.only_restrict_pointers
> +                   && !type_contains_placeholder_p (TREE_TYPE
> (field_type)))
> +                 {
> +                   varinfo_t rvi;
> +                   tree heapvar = build_fake_var_decl (TREE_TYPE
> (field_type));
> +                   DECL_EXTERNAL (heapvar) = 1;
> +                   rvi = create_variable_info_for_1 (heapvar,
> "PARM_NOALIAS",
> +                                                     true, true);
> +                   rvi->is_restrict_var = 1;
> +                   insert_vi_for_tree (heapvar, rvi);
> +                   e.restrict_var = rvi;
> +                 }
>
> hmm, can you delay this to the point we actually will use field-sensitive
> stuff?  That is, until create_variable_info_for_1 decided to use a
> multi-field variable?

AFAIU your concern is that in the current patch we're creating heapvars 
that may end up being ignored, f.i. if we hit the 
MAX_FIELDS_FOR_FIELD_SENSITIVE threshold?

>  Say, here:
>
> +      if (handle_param
> +         && newvi->only_restrict_pointers
> +         && fo->restrict_var != NULL)
> +       {
> +         make_constraint_from (newvi, fo->restrict_var->id);
> +         make_param_constraints (fo->restrict_var);
> +       }
>
> ?  Looks like then you don't need the new field at all.
>

The build_fake_var_decl call needs TREE_TYPE (field_type), the type the 
restrict pointer field points to.

The field type is no longer available once we've abstracted the struct 
type into a field stack in create_variable_info_for_1.

I think I can postpone the creation of the heapvar till where you 
suggest in create_variable_info_for_1, but I'd still need a means
to communicate the TREE_TYPE (field_type) from 
push_fields_onto_fieldstack to create_variable_info_for_1.

A simple implementation would be a new field:
...
@@ -5195,6 +5197,8 @@ struct fieldoff
unsigned may_have_pointers : 1;

unsigned only_restrict_pointers : 1;
+
+ tree restrict_pointed_type;
};
...
Which AFAIU will change fieldoff size.

Thanks,
- Tom