Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message < 200003292249.RAA29751@caip.rutgers.edu >you write:
 >   > So I naively tried the type based stuff, using get_alias_type() on the
 >   > TREE_VALUE() of the parameters.  But I quickly saw that by the time I
 >   > got the argument trees, they were already both of type void* so the
 >   > types aliased to the same set.  (At least that's my uneducated guess,
 >   > they were both in the same set #11, while the length parameter was in
 >   > set #9.)
 > By definition, a void * can alias anything (just like a char *).

Right, but then shouldn't it have returned set 0, not 11?  Anyway, for
the question at hand, I don't think type based aliasing is
appropriate.  I was just playing around with it...


 > 
 >   > Then I thought the base ptr stuff might be useful, but I wasn't sure
 >   > how to access that code.  Any pointers?  (No pun intended...)
 > The code is not designed for you to be able to independently ask about
 > type or base pointer aliasing questions, but  instead can pointers A and
 > B alias each other -- if it returns yes, then they may alias, you don't
 > know how or why, only that they may alias.
 > 
 > I don't think adding separate queries of this nature would be a good idea.
 > jeff

I didn't plan to add any new queries.  What you describe is exactly
what I wanted to do.

If I can test whether the src and dst pointers passed to memmove _may_
alias each other and the existing query tells me they don't, then its
safe to call expand_builtin_memcpy in place of memmove.  Right?

So can you point me at existing code which does this?  Given some
examples, I'll try and figure out how to do this on my own.  (If only
for fun, whether I produce something useful can be evaluated later.)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Jeffrey A Law]

  In message < 200003292334.SAA02200@caip.rutgers.edu >you write:
  > Right, but then shouldn't it have returned set 0, not 11? 
Depends on the code :-)  I believe if you had casted the arg to a void *
then you would have got an alias set zero.  Actually, wait, you have two
pointers, not two MEMs -- how are you checking alias sets in that case
since the alias set is a property of the MEM, not the address.

So, no, I don't see a way to do easily what you want since our aliasing
code is designed to work on MEMs, not addresses.

You might be able to generate a MEM with the unknown alias set (-1 I think)
and pass that to the aliasing routines.  Not really sure.

jeff

Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Jeffrey A Law]

  In message < 200003300012.TAA03981@caip.rutgers.edu >you write:
  > I wasn't doing any casting, but the prototype of memmove may have done
  > that for me.
No, a prototype will not do a cast.  You would have to do the cast yourself.

  > Anway, here is what I am talking about.  Assume the following is in a
  > new expand_builtin_memmove() routine, where `arglist' is the tree
  > chain of parameters passed to the expanded memmove call:
  > 
  > +      tree dst = TREE_VALUE (arglist);
  > +      tree src = TREE_VALUE (TREE_CHAIN (arglist));
  > +      tree len = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (arglist)));
  > +      const int dst_set = get_alias_set (dst);
  > +      const int src_set = get_alias_set (src);
  > +      const int len_set = get_alias_set (len);
  > +
  > +      fprintf (stderr, "src=%d, dst=%d, len=%d\n",
  > +              src_set, dst_set, len_set);
  > +
  > +      if (src_set <= 0 || dst_set <= 0 || src_set == dst_set)
  > +       return 0;
  > +      else
  > +       return expand_builtin_memcpy (arglist);
As I mentioned before, the aliasing code wants MEMs.  You're not even really
supposed to be calling get_alias_set like that.  You're supposed to be calling
stuff like true_dependence and the like (see alias.c).




jeff

Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message < 200003292334.SAA02200@caip.rutgers.edu >you write:
 >   > Right, but then shouldn't it have returned set 0, not 11? 
 > 
 > Depends on the code :-)  I believe if you had casted the arg to a void *
 > then you would have got an alias set zero.  Actually, wait, you have two
 > pointers, not two MEMs -- how are you checking alias sets in that case
 > since the alias set is a property of the MEM, not the address.

I wasn't doing any casting, but the prototype of memmove may have done
that for me.

Anway, here is what I am talking about.  Assume the following is in a
new expand_builtin_memmove() routine, where `arglist' is the tree
chain of parameters passed to the expanded memmove call:

+      tree dst = TREE_VALUE (arglist);
+      tree src = TREE_VALUE (TREE_CHAIN (arglist));
+      tree len = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (arglist)));
+      const int dst_set = get_alias_set (dst);
+      const int src_set = get_alias_set (src);
+      const int len_set = get_alias_set (len);
+
+      fprintf (stderr, "src=%d, dst=%d, len=%d\n",
+              src_set, dst_set, len_set);
+
+      if (src_set <= 0 || dst_set <= 0 || src_set == dst_set)
+       return 0;
+      else
+       return expand_builtin_memcpy (arglist);

Given a call to memmove(int[], char[], size_t) I was getting 11, 11, 9
for the alias sets.  Maybe I'm not using the type based aliasing
correctly.  (Docs somewhere?)  In any case, I'm now interested in the
base ptr aliasing code.


 > So, no, I don't see a way to do easily what you want since our aliasing
 > code is designed to work on MEMs, not addresses.
 > 
 > You might be able to generate a MEM with the unknown alias set (-1 I think)
 > and pass that to the aliasing routines.  Not really sure.
 > jeff

Okay, what routine?

I couldn't figure out what the relevant exported interface to the base
ptr aliasing I should try.  Randomly looking in alias.c wasn't very
productive.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Jeffrey A Law]

  In message < 200003292249.RAA29751@caip.rutgers.edu >you write:
  > So I naively tried the type based stuff, using get_alias_type() on the
  > TREE_VALUE() of the parameters.  But I quickly saw that by the time I
  > got the argument trees, they were already both of type void* so the
  > types aliased to the same set.  (At least that's my uneducated guess,
  > they were both in the same set #11, while the length parameter was in
  > set #9.)
By definition, a void * can alias anything (just like a char *).

  > Then I thought the base ptr stuff might be useful, but I wasn't sure
  > how to access that code.  Any pointers?  (No pun intended...)
The code is not designed for you to be able to independently ask about
type or base pointer aliasing questions, but  instead can pointers A and
B alias each other -- if it returns yes, then they may alias, you don't
know how or why, only that they may alias.

I don't think adding separate queries of this nature would be a good idea.
jeff

Would alias analysis help WRT builtin memmove -> builtin memcpy ?

[Kaveh R. Ghazi]

When looking at the existing builtin memcpy, it occurred to me that
perhaps one could use alias analysis to determine whether the pointer
parameters passed to memmove aliased each other and if not, then
implement a builtin memmove in terms of builtin memcpy.

So I naively tried the type based stuff, using get_alias_type() on the
TREE_VALUE() of the parameters.  But I quickly saw that by the time I
got the argument trees, they were already both of type void* so the
types aliased to the same set.  (At least that's my uneducated guess,
they were both in the same set #11, while the length parameter was in
set #9.)

Then I thought the base ptr stuff might be useful, but I wasn't sure
how to access that code.  Any pointers?  (No pun intended...)

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions