Optimize load from aggregate stores

deadal nix deadalnix at gmail.com
Sat Apr 12 01:27:16 PDT 2014


ping ping.

I've been asked for sample IR where it makes a difference. Here you go:

%A__vtbl = type { i8*, i32 (%A*)* }
%A = type { %A__vtbl* }

@A__vtblZ = constant %A__vtbl { i8* null, i32 (%A*)* @A.foo }
@A__initZ = constant %A { %A__vtbl* @A__vtblZ }

define i32 @_Dmain() {
body:
  %0 = tail call i8* @_d_allocmemory(i64 8)
  %1 = bitcast i8* %0 to %A*
  store %A { %A__vtbl* @A__vtblZ }, %A* %1, align 8
  %2 = getelementptr inbounds %A* %1, i32 0, i32 0
  %vtbl.i = load %A__vtbl** %2, align 8
  %3 = getelementptr inbounds %A__vtbl* %vtbl.i, i64 0, i32 1
  %4 = load i32 (%A*)** %3, align 8
  %5 = tail call i32 %4(%A* %1)
  ret i32 %5
}

define i32 @A.foo(%A* nocapture %this) nounwind readnone {
body:
  ret i32 42
}


Basically, any frontend that uses aggregate store will benefit greatly from
this patch. Right now, if you store an aggregate and load from the
aggregate, LLVM do not optimize at all.

As far as i'm aware, it is considered a bug by clang devs to use aggregate
stores/loads, and they aren't used as a result, so the optimization won't
improve things for clang.



2014-03-22 22:40 GMT-07:00 deadal nix <deadalnix at gmail.com>:

> I can't find the thread where this was discussed. I made a diff some time
> ago. Here is the same updated and with improved test coverage.
>
> Currently, LLVM really misoptimize aggregate load/store. This diff is a
> big improvement on that side.
>
> Amaury SECHET
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140412/33eec44b/attachment.html>


More information about the llvm-commits mailing list