maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llgo/test/irgen/imports.go

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

21 lines
515 B
Go
Raw Normal View History

irgen: modify the ABI to use init guards instead of priority The new ABI is simpler for use cases such as dynamically loaded packages. The calling convention for import functions is similar to what go/ssa would produce if BareInits were cleared. However, simply clearing this flag causes two additional issues: 1) We would need to special case the 'init$guard' variable (see discussion in https://codereview.appspot.com/78780043/). 2) The call to __go_register_gc_roots needs to appear in the right place, i.e. after the guard check. Making this check appear in the right place with non-bare inits seems unreliable at best. So we keep BareInits set and generate the necessary code manually. It is still possible to get the old ABI by specifying a path to a gccgo installation. Differential Revision: http://reviews.llvm.org/D6804 llvm-svn: 225030
2014-12-31 08:25:39 +08:00
// RUN: llgo -S -emit-llvm -o - %s | FileCheck %s
package foo
import _ "fmt"
var X interface{}
// CHECK: @"init$guard" = internal global i1 false
Roll gofrontend to 07baa07598ea; roll libffi to r219477. Incorporates https://codereview.appspot.com/198770044, which causes us to start using the static chain register for closures instead of __go_{get,set}_closure. Differential Revision: http://reviews.llvm.org/D8829 llvm-svn: 234135
2015-04-06 07:31:49 +08:00
// CHECK: define void @foo..import(i8* nest)
irgen: modify the ABI to use init guards instead of priority The new ABI is simpler for use cases such as dynamically loaded packages. The calling convention for import functions is similar to what go/ssa would produce if BareInits were cleared. However, simply clearing this flag causes two additional issues: 1) We would need to special case the 'init$guard' variable (see discussion in https://codereview.appspot.com/78780043/). 2) The call to __go_register_gc_roots needs to appear in the right place, i.e. after the guard check. Making this check appear in the right place with non-bare inits seems unreliable at best. So we keep BareInits set and generate the necessary code manually. It is still possible to get the old ABI by specifying a path to a gccgo installation. Differential Revision: http://reviews.llvm.org/D6804 llvm-svn: 225030
2014-12-31 08:25:39 +08:00
// CHECK-NEXT: :
Fix test to use explicit load type. llvm-svn: 231417
2015-03-06 06:55:42 +08:00
// CHECK-NEXT: %[[N:.*]] = load i1, i1* @"init$guard"
irgen: modify the ABI to use init guards instead of priority The new ABI is simpler for use cases such as dynamically loaded packages. The calling convention for import functions is similar to what go/ssa would produce if BareInits were cleared. However, simply clearing this flag causes two additional issues: 1) We would need to special case the 'init$guard' variable (see discussion in https://codereview.appspot.com/78780043/). 2) The call to __go_register_gc_roots needs to appear in the right place, i.e. after the guard check. Making this check appear in the right place with non-bare inits seems unreliable at best. So we keep BareInits set and generate the necessary code manually. It is still possible to get the old ABI by specifying a path to a gccgo installation. Differential Revision: http://reviews.llvm.org/D6804 llvm-svn: 225030
2014-12-31 08:25:39 +08:00
// CHECK-NEXT: br i1 %[[N]], label %{{.*}}, label %[[L:.*]]
IR: Support parsing numeric block ids, and emit them in textual output. Just as as llvm IR supports explicitly specifying numeric value ids for instructions, and emits them by default in textual output, now do the same for blocks. This is a slightly incompatible change in the textual IR format. Previously, llvm would parse numeric labels as string names. E.g. define void @f() { br label %"55" 55: ret void } defined a label *named* "55", even without needing to be quoted, while the reference required quoting. Now, if you intend a block label which looks like a value number to be a name, you must quote it in the definition too (e.g. `"55":`). Previously, llvm would print nameless blocks only as a comment, and would omit it if there was no predecessor. This could cause confusion for readers of the IR, just as unnamed instructions did prior to the addition of "%5 = " syntax, back in 2008 (PR2480). Now, it will always print a label for an unnamed block, with the exception of the entry block. (IMO it may be better to print it for the entry-block as well. However, that requires updating many more tests.) Thus, the following is supported, and is the canonical printing: define i32 @f(i32, i32) { %3 = add i32 %0, %1 br label %4 4: ret i32 %3 } New test cases covering this behavior are added, and other tests updated as required. Differential Revision: https://reviews.llvm.org/D58548 llvm-svn: 356789
2019-03-23 02:27:13 +08:00
// CHECK: [[L]]:
irgen: modify the ABI to use init guards instead of priority The new ABI is simpler for use cases such as dynamically loaded packages. The calling convention for import functions is similar to what go/ssa would produce if BareInits were cleared. However, simply clearing this flag causes two additional issues: 1) We would need to special case the 'init$guard' variable (see discussion in https://codereview.appspot.com/78780043/). 2) The call to __go_register_gc_roots needs to appear in the right place, i.e. after the guard check. Making this check appear in the right place with non-bare inits seems unreliable at best. So we keep BareInits set and generate the necessary code manually. It is still possible to get the old ABI by specifying a path to a gccgo installation. Differential Revision: http://reviews.llvm.org/D6804 llvm-svn: 225030
2014-12-31 08:25:39 +08:00
// CHECK-NEXT: call void @__go_register_gc_roots
// CHECK-NEXT: store i1 true, i1* @"init$guard"
Roll gofrontend to 07baa07598ea; roll libffi to r219477. Incorporates https://codereview.appspot.com/198770044, which causes us to start using the static chain register for closures instead of __go_{get,set}_closure. Differential Revision: http://reviews.llvm.org/D8829 llvm-svn: 234135
2015-04-06 07:31:49 +08:00
// CHECK-NEXT: call void @fmt..import(i8* undef)
irgen: modify the ABI to use init guards instead of priority The new ABI is simpler for use cases such as dynamically loaded packages. The calling convention for import functions is similar to what go/ssa would produce if BareInits were cleared. However, simply clearing this flag causes two additional issues: 1) We would need to special case the 'init$guard' variable (see discussion in https://codereview.appspot.com/78780043/). 2) The call to __go_register_gc_roots needs to appear in the right place, i.e. after the guard check. Making this check appear in the right place with non-bare inits seems unreliable at best. So we keep BareInits set and generate the necessary code manually. It is still possible to get the old ABI by specifying a path to a gccgo installation. Differential Revision: http://reviews.llvm.org/D6804 llvm-svn: 225030
2014-12-31 08:25:39 +08:00
// CHECK-NEXT: br label