llvm dev - Feb 2015 - [LLVMdev] Eliminating redundant loads

Hi,

I am generating following code:

  %base = getelementptr inbounds %ravi.CallInfo* %6, i32 0, i32 4, i32 0
  %7 = load %ravi.TValue** %base
  %8 = bitcast %ravi.TValue* %7 to i8*
  %9 = bitcast %ravi.TValue* %5 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %8, i8* %9, i32 16, i32 8, i1 false)
  %10 = load %ravi.CallInfo** %L_ci
  %base1 = getelementptr inbounds %ravi.CallInfo* %10, i32 0, i32 4, i32 0
  %11 = load %ravi.TValue** %base1
  %12 = getelementptr inbounds %ravi.TValue* %11, i32 1
  %13 = getelementptr inbounds %ravi.TValue* %5, i32 1
  %14 = bitcast %ravi.TValue* %12 to i8*
  %15 = bitcast %ravi.TValue* %13 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %14, i8* %15, i32 16, i32 8, i1 false
)
  %16 = load %ravi.CallInfo** %L_ci
  %base2 = getelementptr inbounds %ravi.CallInfo* %16, i32 0, i32 4, i32 0
  %17 = load %ravi.TValue** %base2

Now base, base2 and base1 are really the same - i.e., nothing's
happened to change the pointer held at this location. So should I
expect the redundant getelementptr and load instructions to be
eliminated during optimization phase?

I am using the optimisation passes as described in Kaleidoscope
tutorial but it seems that the redundant loads are not being removed.

Is it the call to memcpy that's preventing this?

Thanks and Regards
Dibyendu

Not sure if this is your problem, but it was mine:

You must create (or obtain) a DataLayout *and install it into the Module*.

It is possible to generate machine code for IR and not install the
DataLayout into the Module. Rather, the DataLayout is used locally at the
point where code is generated. However, if you do this, then the alias
analyses required to get rid of your redundant loads and stores cannot
reason about possible aliasing.



On Sun, Feb 22, 2015 at 3:42 PM, Dibyendu Majumdar <mobile at
majumdar.org.uk>
wrote:
> Hi,
>
> I am generating following code:
>
>   %base = getelementptr inbounds %ravi.CallInfo* %6, i32 0, i32 4, i32 0
>   %7 = load %ravi.TValue** %base
>   %8 = bitcast %ravi.TValue* %7 to i8*
>   %9 = bitcast %ravi.TValue* %5 to i8*
>   call void @llvm.memcpy.p0i8.p0i8.i32(i8* %8, i8* %9, i32 16, i32 8, i1
> false)
>   %10 = load %ravi.CallInfo** %L_ci
>   %base1 = getelementptr inbounds %ravi.CallInfo* %10, i32 0, i32 4, i32 0
>   %11 = load %ravi.TValue** %base1
>   %12 = getelementptr inbounds %ravi.TValue* %11, i32 1
>   %13 = getelementptr inbounds %ravi.TValue* %5, i32 1
>   %14 = bitcast %ravi.TValue* %12 to i8*
>   %15 = bitcast %ravi.TValue* %13 to i8*
>   call void @llvm.memcpy.p0i8.p0i8.i32(i8* %14, i8* %15, i32 16, i32 8, i1
> false
> )
>   %16 = load %ravi.CallInfo** %L_ci
>   %base2 = getelementptr inbounds %ravi.CallInfo* %16, i32 0, i32 4, i32 0
>   %17 = load %ravi.TValue** %base2
>
> Now base, base2 and base1 are really the same - i.e., nothing's
> happened to change the pointer held at this location. So should I
> expect the redundant getelementptr and load instructions to be
> eliminated during optimization phase?
>
> I am using the optimisation passes as described in Kaleidoscope
> tutorial but it seems that the redundant loads are not being removed.
>
> Is it the call to memcpy that's preventing this?
>
> Thanks and Regards
> Dibyendu
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150222/92c1e621/attachment.html>

On 22 February 2015 at 20:58, David Jones <djones at xtreme-eda.com>
wrote:
> Not sure if this is your problem, but it was mine:
>
> You must create (or obtain) a DataLayout *and install it into the Module*.
>
> It is possible to generate machine code for IR and not install the
> DataLayout into the Module. Rather, the DataLayout is used locally at the
> point where code is generated. However, if you do this, then the alias
> analyses required to get rid of your redundant loads and stores cannot
> reason about possible aliasing.
>
Hi David,

I tried setting the module's DataLayout  to the engine's DataLayout.
Don't see any improvement.
The memcpy() is to perform a struct assign, so I tried replacing that
with member by member store.
But even then the loads are not being eliminated so I guess the
memcpy() isn't the issue.

Regards
Dibyendu