IRGen's swift_rt_* functions


(Slava Pestov) #1

Hi all,

Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* wrappers around runtime calls? They look like no-ops at this point since the runtime entry points themselves should be swiftcc with the callee save variant?

Slava


(Jordan Rose) #2

I believe these are interposition points for things like dtrace, and also useful for Roman's experiments with nonatomic retain counting. Roman, do you know?

(JoeG would know too but he's on vacation.)

Jordan

···

On Apr 24, 2017, at 17:15, Slava Pestov via swift-dev <swift-dev@swift.org> wrote:

Hi all,

Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* wrappers around runtime calls? They look like no-ops at this point since the runtime entry points themselves should be swiftcc with the callee save variant?

Slava
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Roman Levenstein) #3

I believe these are interposition points for things like dtrace, and also useful for Roman's experiments with nonatomic retain counting. Roman, do you know?

I had a chat with Slava yesterday and explained it to him.

But basically, these are for the special calling convention to be used for invocation of often used runtime entry points (e.g. reference counting functions like swift_retain). This calling convention is not enabled by default yet. But the idea is that it provides more callee-saved registers thus giving the caller more registers that can be used without spilling them around the calls of such a runtime entry. And wrappers are required because otherwise dyld (the dynamic linker) in certain situations clobbers some of these callee-saved registers.

-Roman

···

On Apr 25, 2017, at 11:18 AM, Jordan Rose <jordan_rose@apple.com> wrote:

(JoeG would know too but he's on vacation.)

Jordan

On Apr 24, 2017, at 17:15, Slava Pestov via swift-dev <swift-dev@swift.org> wrote:

Hi all,

Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* wrappers around runtime calls? They look like no-ops at this point since the runtime entry points themselves should be swiftcc with the callee save variant?

Slava
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Michael Gottesman) #4

I believe these are interposition points for things like dtrace, and also useful for Roman's experiments with nonatomic retain counting. Roman, do you know?

I had a chat with Slava yesterday and explained it to him.

But basically, these are for the special calling convention to be used for invocation of often used runtime entry points (e.g. reference counting functions like swift_retain). This calling convention is not enabled by default yet. But the idea is that it provides more callee-saved registers thus giving the caller more registers that can be used without spilling them around the calls of such a runtime entry. And wrappers are required because otherwise dyld (the dynamic linker) in certain situations clobbers some of these callee-saved registers.

Can we document this in ./docs somewhere?

···

On Apr 25, 2017, at 11:24 AM, Roman Levenstein via swift-dev <swift-dev@swift.org> wrote:

On Apr 25, 2017, at 11:18 AM, Jordan Rose <jordan_rose@apple.com> wrote:

-Roman

(JoeG would know too but he's on vacation.)

Jordan

On Apr 24, 2017, at 17:15, Slava Pestov via swift-dev <swift-dev@swift.org> wrote:

Hi all,

Now that we’re using swiftcc, does IRGen still need to emit the swift_rt_* wrappers around runtime calls? They look like no-ops at this point since the runtime entry points themselves should be swiftcc with the callee save variant?

Slava
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev