Memory barrier problem

>So a weaker `noalias` or a way to mark uses seems therefore required for
>`noalias` deduction.

Appears to be that way. Can we do that w/o having a weaker restrict in the
language spec?

The full restrict[0] implementation does not depend on the 'noalias' attribute on
function arguments. The attribute is even too strong for just mapping a
'C99 restrict pointer argument' to a 'LLVM-IR noalias pointer argument'.
For backwards compatibility, I kept the default mapping of restrict pointer arguments
onto 'noalias' and provided the '-fno-noalias-arguments' option to disable this mapping
For some code, this can result in a wrong 'based on' deduction.[1]

Given that, IMHO, it still makes sense to have a strong and a weaker version of the
'noalias argument attribute'. At least, the stronger (current 'noalias') version can be
converted to the noalias scope/intrinsics mapping during inlining, keeping the strong guarantees.
Converting a weaker version likely will need some more tweaking.

The noalias attribute is also used for a struct pointer argument when a function returns a struct.

Greetings,

Jeroen Dobbelaere
[0] Full Restrict patches: https://reviews.llvm.org/D68484
[1] 'clang/test/CodeGen/restrict/arg_reuse.c' testcase in: https://reviews.llvm.org/D68521

So a weaker `noalias` or a way to mark uses seems therefore required for
`noalias` deduction.

Appears to be that way. Can we do that w/o having a weaker restrict in the
language spec?

The full restrict[0] implementation does not depend on the 'noalias' attribute on
function arguments. The attribute is even too strong for just mapping a
'C99 restrict pointer argument' to a 'LLVM-IR noalias pointer argument'.
For backwards compatibility, I kept the default mapping of restrict pointer arguments
onto 'noalias' and provided the '-fno-noalias-arguments' option to disable this mapping
For some code, this can result in a wrong 'based on' deduction.[1]

Given that, IMHO, it still makes sense to have a strong and a weaker version of the
'noalias argument attribute'. At least, the stronger (current 'noalias') version can be
converted to the noalias scope/intrinsics mapping during inlining, keeping the strong guarantees.
Converting a weaker version likely will need some more tweaking.

The noalias attribute is also used for a struct pointer argument when a function returns a struct.

Interesting. I guess we would not keep it for restrict if it is too strong but there
are other uses where the guarantees are useful I believe.

Given that full restrict will make the `__restrict` problem go away, let's look at the
deduction one.

What if we make `nosync` a value/pointer attribute as well and then have:

`noalias`
Does not alias other pointers in scope but synchronizing events might still change
the value because other threads might have the same "expression". That is, we declare
the deductions as correct by weakening `noalias`.

`nosync`
The value is not modified in this scope by another thread.

`noalias` + `nosync`
Matches the `__restrict` guarantee that nothing not based of the pointer can modify it,
so this is "stronger" than synchronization events and you can forward over fences/barriers.

WDYT?

~ Johannes

What if we make `nosync` a value/pointer attribute as well and then have:

  `noalias`
  Does not alias other pointers in scope but synchronizing events might still change
  the value because other threads might have the same "expression".
That is, we declare
  the deductions as correct by weakening `noalias`.

  `nosync`
  The value is not modified in this scope by another thread.

  `noalias` + `nosync`
  Matches the `__restrict` guarantee that nothing not based of the pointer can modify it,
  so this is "stronger" than synchronization events and you can forward over fences/barriers.

WDYT?

Sounds like a good new direction to have a debate for the best solution. I think this or a similar variation of this would work to address the original issue Andy brought up,
within the compiler (but probably not between the programmer and the compiler ---- a separate discussion on this?).

Hideki