# Re: \[RFC PATCH\] LKMM: Add ctrl\_dep() macro for control dependency

- From: Linus Torvalds \<torvalds@linux-foundation.org\>
- Date: 2021-10-01 18:19:02 
- List: linux-toolchains
- Page: https://ratatoskr.run/linux-toolchains/2021/10/1528455
- Thread: https://ratatoskr.run/linux-toolchains/2021/09/1525080/t.md

```text
On Fri, Oct 1, 2021 at 10:28 AM Mathieu Desnoyers
[ref] wrote:
>
> I've spent some quality time staring at generated assembler diff in the past
> days, and looking for code patterns of refcount_dec_and_test users, without
> much success. There are some cases which end up working by chance, e.g. in
> cases where the if leg has a smp_acquire__after_ctrl_dep and the else leg has
> code that emits a barrier(), but I did not find any buggy generated
> code per se. In order to observe those issues in real life, we would
> really need to have identical then/else legs to the branch.

Yeah, that's been very much my feeling too during this whole
discussion (including, very much, earlier threads).

All the examples about this being a problem are those kinds of
"identical or near-identical if/else statements" and they just don't
seem to be all that realistic.

Because immediately when the if-statement actually does something
_meaningful_, it just turns into a branch. And when people use atomics
- even the weak READ/WRITE_ONCE() kinds of things, never mind anything
stronger - it really doesn't give the compiler the option to move
things around all that much.

There's a reason the source code uses an if-statement, after all: that
is literally the logical code flow, and people write a very particular
dependency chain that is just very fundamental.

Having essentially the same thing on both sides just isn't a realistic
thing to do, and if it were - and you cared about performance in that
case, which is what this is all about, after all - you'd write it very
differently.

                Linus
```