On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 2:40 PM, torbenh <torb...@gmx.de> wrote:
> > __restrict__ is of no help here. which leads me to the question whats
> > the point of a restricted this pointer ? members of structs arent
> > unaliased by a __restrict__ pointer to the struct.
> >
> > my favourite solution would be __noalias__ ... msvc has that.
> > but -fnoalias would make me happy too.
> >
> > i havent read much of the gcc code yet, so i am not sure what i need to
> > patch.
> >
> > refs_may_alias_p_1() is my current bet though.
>
> 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.
can you please explain, why you reject the idea of -fnoalias ?
msvc has declspec(noalias) icc has -fnoalias
ramp.cc attached.
compiling it with gcc -S -O3 ramp.cc on x86_64 yields:
------------------------------------------------------------
_Z11fill_bufferPfm:
.LFB1:
testq %rsi, %rsi
je .L1
xorl %eax, %eax
movss .LC0(%rip), %xmm2
.align 16
.L3:
movss ramp(%rip), %xmm0
movaps %xmm0, %xmm1
addss %xmm2, %xmm1
movss %xmm1, ramp(%rip)
movss %xmm0, (%rdi,%rax,4)
addq $1, %rax
cmpq %rax, %rsi
ja .L3
.L1:
rep
ret
-----------------------------------------------------------
--
torben Hohn
