target_mem_ref and memory/prefetch intrinsics

[Richard Guenther]

On Fri, Oct 15, 2010 at 9:24 AM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> Hi,
>
>> Hi, We know that ivopt does not know how to handle intrinsic calls and
>> treat iv uses from such 'calls' as non-linear iv use thus the cost
>> estimation of a certain transformation plan is all wrong. For instance
>
> yes, this would be nice to handle (especially for the prefetches).
>
>> __builit_xxxx (addr_expr (target_mem_ref (base, iv, offset, stride), ...)
>>
>> but as far as I can tell, this won't work (I have not tried it
>> though).   What are your suggestions on this?
>
> What you suggest looks workable to me (may require a few changes to gimple.c,
> tree-ssa-operands.c and perhaps some other places, though).  Perhaps easier and
> more consistent would be
>
> tmp = addr_expr (target_mem_ref (...));
> __builtin_xxx (tmp, ...)
>
> which should work as well most of the time, as TER will reduce it to the former.
> Of course, this would break in cases like
>
> tmp1 = addr_expr (target_mem_ref (...));
> __builtin_xxx (tmp1, ...)
> tmp2 = addr_expr (the same target_mem_ref)
> __builtin_yyy (tmp2, ...)
>
> which we would "optimize" to
>
> tmp1 = addr_expr (target_mem_ref (...));
> __builtin_xxx (tmp1, ...)
> __builtin_yyy (tmp1, ...)
>
> thus making us use an unnecessary temporary variable.  So, I would actually prefer
> your suggestion (unless people burn us at stake for violating the sanctity of gimple :-)

Yes, I'll burn you if you start to allow non-invariant addresses in
function arguments ;))

I think using a temporary will already be an improvement over the current
situation, and we can always teach the expander to re-materialize
a CSEd address if we really need to.

Richard.

> Zdenek
>