On Fri, 17 Aug 2007, Nick Piggin wrote:

Satyam Sharma wrote:

quoted

I didn't quite understand what you said here, so I'll tell what I think:

* foo() is a compiler barrier if the definition of foo() is invisible to
 the compiler at a callsite.

* foo() is also a compiler barrier if the definition of foo() includes
 a barrier, and it is inlined at the callsite.

If the above is wrong, or if there's something else at play as well,
do let me know.

[...]
If a function is not completely visible to the compiler (so it can't
determine whether a barrier could be in it or not), then it must always
assume it will contain a barrier so it always does the right thing.

Yup, that's what I'd said just a few sentences above, as you can see. I
was actually asking for "elaboration" on "how a compiler determines that
function foo() (say foo == schedule), even when it cannot see that it has
a barrier(), as you'd mentioned, is a 'sleeping' function" actually, and
whether compilers have a "notion of sleep to automatically assume a
compiler barrier whenever such a sleeping function foo() is called". But
I think you've already qualified the discussion to this kernel, so okay,
I shouldn't nit-pick anymore.