Re: adding -fnoalias ... would a patch be accepted ?

[torbenh <torbenh@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 4:03 PM, torbenh <torbenh@gmx.de> wrote:
> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh <torbenh@gmx.de> wrote:
> >>
> >> The -fno-alias-X things do not make much sense for user code (they
> >> have been historically used from Frontends).  If restrict doesn't work
> >> for you (do you have a testcase that can reproduce your issue?)
> >> then you probably need to wait for IPA pointer analysis to be
> >> fixed in GCC 4.6.
> >
> > sorry... forget the attachment :S
> 
> Yes, in this case you can fix it by making ramp static.  Otherwise its
> address may be takein in another translation unit.  For Fortran we
> have the DECL_RESTRICTED_P which we could expose to other
> languages via an attribute.  It tells that a decl is not aliased by
> restrict qualified pointers, so
> 
> struct Ramp {
>     float phase;
>     inline float process() { return phase++; }
> } ramp __attribute__((restrict));
> 
> void fill_buffer( float * __restrict buf, size_t nframes )
> {
>     for( size_t i=0; i<nframes; i++ )
>         buf[i] = ramp.process();
> }

would that also work with this stuff:


template<typename ... Args>
class Mixer;

template<typename T1, typename ... Args>
class Mixer<T1, Args...> : public Block
{
    private:
	T1 t1 __attribute__((restrict));
	Mixer<Args...> t2;
    public:
	inline float process() {
	    return t1.process() + t2.process();
	}
};

template<typename T1, typename T2>
class Mixer<T1,T2> : public Block
{
    private:
	T1 t1 __attribute__((restrict));
	T2 t2 __attribute__((restrict));
    public:
	inline float process() {
	    return t1.process() + t2.process();
	}
};

Mixer<Ramp,Ramp,Ramp,Ramp> mix __attribute__((restrict))

?

i still dont understand whats the problem with -fnolias,
as in attached patch.

> 
> would then be optimized as well.  Can you file an enhancement
> bugreport according to this?
> 
> Thanks,
> Richard.

-- 
torben Hohn

[-- Attachment #2: noalias.patch --]
[-- Type: text/x-diff, Size: 1385 bytes --]

diff --git a/gcc/common.opt b/gcc/common.opt
index 77967f8..21eebb2 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -834,6 +834,10 @@ freschedule-modulo-scheduled-loops
 Common Report Var(flag_resched_modulo_sched) Optimization
 Enable/Disable the traditional scheduling in loops that already passed modulo scheduling
 
+fnoalias
+Common Report Var(flag_noalias) Optimization
+Assume no aliasing is happening
+
 fnon-call-exceptions
 Common Report Var(flag_non_call_exceptions) Optimization
 Support synchronous non-call exceptions
diff --git a/gcc/opts.c b/gcc/opts.c
index 5407527..9b8639e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2053,6 +2053,10 @@ common_handle_option (size_t scode, const char *arg, int value,
       flag_ipa_cp_clone_set = true;
       break;
 
+    case OPT_fnoalias:
+      flag_noalias = true;
+      break;
+
     case OPT_fpredictive_commoning:
       flag_predictive_commoning_set = true;
       break;
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index cbb43b5..0b66577 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -662,6 +662,9 @@ indirect_ref_may_alias_decl_p (tree ref1, tree ptr1,
   if (!ptr_deref_may_alias_decl_p (ptr1, base2))
     return false;
 
+  if (flag_noalias)
+    return false;
+
   /* Disambiguations that rely on strict aliasing rules follow.  */
   if (!flag_strict_aliasing)
     return true;