Philip Reames via llvm-dev
2021-Jul-20 17:23 UTC
[llvm-dev] Are derived pointers caught by RS4GC?
$ ./opt -S llvm-dev.ll -rewrite-statepoints-for-gc
; ModuleID = 'llvm-dev.ll'
source_filename = "llvm-dev.ll"
define void @dummy_func() {
ret void
}
define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) gc
"statepoint-example" {
%gep = getelementptr i8, i8 addrspace(1)* %obj, i64 20000
%statepoint_token = call token (i64, i32, void ()*, i32, i32, ...)
@llvm.experimental.gc.statepoint.p0f_isVoidf(i64 2882400000, i32 0, void
()* @dummy_func, i32 0, i32 0, i32 0, i32 0) [ "gc-live"(i8
addrspace(1)* %obj) ]
*%obj.relocated = call coldcc i8 addrspace(1)*
@llvm.experimental.gc.relocate.p1i8(token %statepoint_token, i32 0, i32
0) ; (%obj, %obj)*
*%gep.remat = getelementptr i8, i8 addrspace(1)* %obj.relocated, i64 20000*
%p = getelementptr i8, i8 addrspace(1)* %gep.remat, i64 -20000
store i8 2, i8 addrspace(1)* %gep.remat, align 1
ret i8 addrspace(1)* %p
}
Works for me. This output is entirely correct as we relocated the base
pointer and then rematerialized the derived pointer afterwards. This is
almost always profitable over directly relocating both obj and derived
pointers.
Philip
On 7/20/21 7:45 AM, Kavindu Gimhan Zoysa via llvm-dev
wrote:>
> define void @dummy_func() {
> ret void
> }
> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) gc
> "statepoint-example" {
> %gep = getelementptr i8, i8 addrspace(1)* %obj, i64 20000
> call void @dummy_func()
> %p = getelementptr i8, i8 addrspace(1)* %gep, i64 -20000
> store i8 2, i8 addrspace(1)* %gep
> ret i8 addrspace(1)* %p
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210720/9fc46768/attachment.html>
Kavindu Gimhan Zoysa via llvm-dev
2021-Jul-20 18:22 UTC
[llvm-dev] Are derived pointers caught by RS4GC?
Hi Philip, It is the same output I got that make sense. But as explained in this example https://llvm.org/docs/Statepoints.html#base-derived-pointers (the example available in this section), I thought *%gep *should be included in gc-live operand bundle. Isn't that correct? Kavindu Gimhan Zoysa, BSc(Hons) | ENTC | UoM, ATL | WSO2 GitHub <https://github.com/KavinduZoysa> LinkedIn <https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/> Medium <https://medium.com/@kavindugimhanzoysa> On Tue, 20 Jul 2021 at 22:53, Philip Reames <listmail at philipreames.com> wrote:> $ ./opt -S llvm-dev.ll -rewrite-statepoints-for-gc > ; ModuleID = 'llvm-dev.ll' > source_filename = "llvm-dev.ll" > > define void @dummy_func() { > ret void > } > > define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) gc > "statepoint-example" { > %gep = getelementptr i8, i8 addrspace(1)* %obj, i64 20000 > %statepoint_token = call token (i64, i32, void ()*, i32, i32, ...) > @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 2882400000, i32 0, void > ()* @dummy_func, i32 0, i32 0, i32 0, i32 0) [ "gc-live"(i8 addrspace(1)* > %obj) ] > *%obj.relocated = call coldcc i8 addrspace(1)* > @llvm.experimental.gc.relocate.p1i8(token %statepoint_token, i32 0, i32 0) > ; (%obj, %obj)* > *%gep.remat = getelementptr i8, i8 addrspace(1)* %obj.relocated, i64 > 20000* > %p = getelementptr i8, i8 addrspace(1)* %gep.remat, i64 -20000 > store i8 2, i8 addrspace(1)* %gep.remat, align 1 > ret i8 addrspace(1)* %p > } > > Works for me. This output is entirely correct as we relocated the base > pointer and then rematerialized the derived pointer afterwards. This is > almost always profitable over directly relocating both obj and derived > pointers. > > Philip > On 7/20/21 7:45 AM, Kavindu Gimhan Zoysa via llvm-dev wrote: > > > define void @dummy_func() { >> ret void >> } >> define i8 addrspace(1)* @test1(i8 addrspace(1)* %obj) gc >> "statepoint-example" { >> %gep = getelementptr i8, i8 addrspace(1)* %obj, i64 20000 >> call void @dummy_func() >> %p = getelementptr i8, i8 addrspace(1)* %gep, i64 -20000 >> store i8 2, i8 addrspace(1)* %gep >> ret i8 addrspace(1)* %p >> } > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210720/abb22fe1/attachment.html>