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: target_mem_ref and memory/prefetch intrinsics


Hi,

> >> Yes, I'll burn you if you start to allow non-invariant addresses in
> >> function arguments ;))
> >
> > could you please give some more justification for that? ?We already allow
> > memory references as function arguments, so it is not as if it made anything
> > more complicated,
> 
> Indeed, and I'd like to get rid of memory references as function arguments
> (we only allow them for things that cannot be assigned to registers anyway).
> 
> If you'd allow &a[i] then why wouldn't you allow &a + 4*i for example.
> 
> The issue is that when we allow this we'll not be able to CSE those
> addresses, we won't be able to propagate into them (consider
> p = &a; foo (&p->a[i]);) with the current generic code but we'd have
> to duplicate it for call arguments.  Etc.

the point of TARGET_MEM_REFs is precisely to avoid such optimizations (which
usually make things worse by destroying the possibility to use addressing modes).
So, I see that as an advantage :-)

The proposal would be to allow only addresses of TARGET_MEM_REFs to appear
as arguments (and even that, only on the few selected builtins that can take the
advantage of addressing modes).

Anyway, I do not have strong preference for this; for now we can go with taking
the address of TARGET_MEM_REFs separately, and see if that is sufficient,

Zdenek


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