[llvm-dev] Which pass should be propagating memory copies

[Peter Lawrence via llvm-dev]

Keno,
          Perhaps you can view the problem to be the memcpys themselves,
We humans can look at the memcpys and see loads and stores
but to almost all optimizer passes they aren’t what it is looking for,
They instead see function calls which they mostly don’t touch,

If these memcpys were inlined into plain old loads and stores
The redundant loads and stores should be deleted by existing opts

A question I have for you is, because this looks like “copy-in-copy-out” argument semantics,
Which to me looks more like Ada than C, what was the source language ?


Peter Lawrence.



> On May 16, 2017, at 12:00 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> On May 16, 2017, at 12:37 PM, Keno Fischer via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org><mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote:
> 
> Consider the following IR example:
> 
> define void @simple([4 x double] *%ptr, i64 %idx) {
>    %stack = alloca [4 x double]
>    %ptri8 = bitcast [4 x double] *%ptr to i8*
>    %stacki8 = bitcast [4 x double] *%stack to i8*
>    call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0)
>    %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx
>    store double 0.0, double *%dataptr
>    call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%ptri8, i8 *%stacki8, i32 32, i32 0, i1 0)
>    ret void
> }
> 
> 
> I would like to see this optimized to just a single store (into %ptr). Right now, even at -O3 that doesn't happen. My frontend guarantees that idx is always inbounds for the allocation, but I do think the transformation should be valid regardless because accessing beyond the bounds of the alloca should be undefined behavior. Now, my question is which pass should be responsible for doing this? SROA? DSE? GVN? A new pass just to do this kind of thing? Maybe there already is some pass that does this, just not in the default pipeline? Any hints would be much appreciated.
> 
> Thanks,
> Keno

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170516/74788627/attachment.html>