On 25 Sep 2005 10:10:39 -0700, Ian Lance Taylor wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > second, how often does this actually set anything useful with restrict
> > types (I assume the value is not interesting in any other cases)?
>
> In functions which use the restrict qualifier, i
Daniel Berlin <[EMAIL PROTECTED]> writes:
> second, how often does this actually set anything useful with restrict
> types (I assume the value is not interesting in any other cases)?
In functions which use the restrict qualifier, it does something
useful pretty often: just about every time the re
> +
> /* Create a new temporary name with PREFIX. Returns an identifier. */
>
> static GTY(()) unsigned int tmp_var_id_num;
> @@ -470,6 +521,18 @@ internal_get_tmp_var (tree val, tree *pr
>
>t = lookup_tmp_var (val, is_formal);
>
> + if (is_formal)
> +{
> + tree u = find_sin
Ian Lance Taylor writes:
> I mentioned on IRC that I had a simple patch to let the RTL level
> aliasing analysis see the underlying decl, the one with the restrict
> qualifier. My original patch was for the 4.0 branch. This is a
> version updated for the 4.1 branch.
I forgot to add the effects
In gcc 4.0, the restrict qualifier became less useful than in gcc 3.4.
One of the main uses of the restrict qualifier is in scheduling. The
scheduler currently uses only RTL level aliasing information--we
currently have no mechanism for letting the RTL level query the alias
information at the tree
