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: [PATCH] Fix the one entry mem{{,p}cpy,move,set} optimization aliasing issues (PR middle-end/29272)


Jakub Jelinek wrote:

Here is an updated patch even with the testcase. As long as &p->t is not
considered an access to *p nor p->t (from Joseph's http://gcc.gnu.org/ml/gcc/2004-11/msg00978.html
mail I gather that it is unclear in the standard, but both common sense
and that mail suggests that &p->t is more likely not considered an access
to *p nor p->t), I believe the testcase is valid.

I would like Joseph's opinion on the testcase. Joseph, do you believe this should be a valid program? I say "should", because I recognize that the standard doesn't necessarily clearly define this case.


+  /* If var is a VAR_DECL or a component thereof,
+     we can use its alias set, otherwise we'd need to make
+     sure we go through alias set 0.  */
+  inner = var;
+  while (handled_component_p (inner))
+    inner = TREE_OPERAND (inner, 0);
+  if (! SSA_VAR_P (inner))
+    return 0;

This predicate should be factored out as a function, so that we avoid code duplication. It looks like your solution means that we're not going to use an inline block copy (and will instead call the libc version of memset) for cases like those in your testcase. That doesn't seem desirable, but if it's the only way to get correct code, that's what we have to do.


However, I think that Ian's suggesting that we don't need to be so conservative. Ian, am I following correctly?

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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