PATCH: Loop to builtin call pass (builtinizer)

Zdenek Dvorak rakdver@kam.mff.cuni.cz
Wed Jul 4 11:24:00 GMT 2007


Hello,

> >> > +     NEXT_PASS (pass_builtinize);
> >> > +     NEXT_PASS (pass_may_alias);
> >>
> >> The pass_may_alias is not necessary.
> >
> >At least in current implemetation i need may_alias pass. I have small
> >example that without may_alias pass fails. The example is:
> >
> >int main (void)
> >{
> >  int i;
> >  float a[N] __attribute__ ((__aligned__(16)));
> >  float b[N] __attribute__ ((__aligned__(16)));
> >
> >  for (i=0; i<N; i++) b[i] = 2; /* (a) */
> >
> >  for (i = 1; i <= 256; i++) a[i] = b[i-1]; /* (b) */
> >
> >  /* check results:  */
> >  for (i = 1; i <= 256; i++)
> >    {
> >      if (a[i] != i-1)
> >        abort1 (3);
> >    }
> >
> >  return 0;
> >}
> >
> >When i compile this example with "-ftree-vectorize
> >-ftree-loop-builtinize ..." than the check fails because dce_loop pass
> >remove all vecorized stmts in (a) that make vectorizer. Problem is
> >that after builinization of (b) a new stmt with __builtin_memcpy (a +
> >4, b, 256) has not VDEFs.
> 
> Did you call mark_stmt_modified/update_stmt?
> That should force the vdefs/vuses to be there.

the problem is that a and b are not call clobbered, thus no vops are
created for them at the __builtin_memcpy call.  Running whole may_alias
pass to fix this problem still seems like an overkill to me.

One possibility is to mark the variables as call clobbered (and rescan
operands of all calls in the functions).

The common problem of using may_alias pass or the procedure described in
the previous paragraph is that the variables are marked as call
clobbered everywhere (although they are only touched by this single
call), so it may prevent optimizations in other parts of the functions.
Unfortunately, at the moment there is no way how to ensure that the
VOPs are added just to this single statement (as VOPs are recomputed
each time the statement is modified).

Zdenek



More information about the Gcc-patches mailing list