Atomic with @_noLocks can cause metadata allocation or locks

Using Swift
21

Thank you! But I think I am still a bit confused what should we take out from this.

It seems to me that relying on optimiser when using Atomics is not guaranteed predictable performance which was one of the main goals of ownership features?

I don't know if this was discussed elsewhere, but is the goal of Atomics to be free of metadata access in a guaranteed and predictable way?

1 Like
22

The only thing preventing Atomic from being used in @_noLocks or @_noAllocation is the deinit devirtualizer. Once that's turned on, you should be able to use atomics in those contexts without any problem.

1 Like
23

Thank you @Alejandro! I think I am starting to understand, but few things are still not clear to me.

My current understanding is that deinit devirtualizer is guaranteed optimisation pass that is happening before performance diagnostic pass. Therefore, diagnostics are performed after problematic code is transformed. Is this right?

If yes, I have few questions:

  • In your godbolt snippet you used -O. Without -O, there are still metadata accesses. My understanding is that this should not be the case for mandatory optimisations?
  • I don't seem to be able to get @_noLocks to compile even with -O with -Xllvm -enable-deinit-devirtualizer.
  • Is there a plan to enable deinit devirtulizer by default?
24

cc: @Erik_Eckstein

25

A part of the issue is fixed here.

The other part seems to be related to @_rawLayout and is filed as a bug here.

26

The other part of the issue related to rawLayout is also fixed.

There is another problem now filed as a bug here.

27

Fixed here.

Thanks everyone!

1 Like