[PATCH] [OPENMP] Codegen for "omp flush" directive.

[John McCall]

On Tue, Nov 25, 2014 at 5:16 AM, Cownie, James H <james.h.cownie at intel.com>
wrote:

> From a runtime point of view we need to preserve backwards binary
> compatibility, so we can't change the interface to the current interface
> function to introduce a count (because that old code won't set it).
>

Okay.  I wasn't sure if you were guaranteeing backwards binary
compatibility with existing compiles or not.  The way that I understand
you're currently deploying the runtime — linking in a static library that's
distributed with the compiler — does not actually require backwards binary
compatibility as far as I can tell.  But if you're making that guarantee,
then I agree we can't break it.


> I would therefore prefer to do this
>
> 1) Change the prototype for the existing function so that it becomes a
> function with no arguments. (Effectively your #1). Since no existing code
> passes arguments, this is fine.
>

Changing from a variadic to a non-variadic function is technically allowed
to break the ABI, e.g. by passing the non-optional arguments in a different
way.  I don't know of any platforms where it does actually change for the
standard C calling convention, though — I know of platforms (like MIPS and
Apple's ARM64) that change how variadic arguments are passed, but not of
any that affect earlier arguments.  And I *think* there's no issue with new
compilations calling old runtimes on platforms like x86-64 where variadic
functions expect extra information, because I don't know of any compilers
that actually crash on an out-of-range value in %al.

So this is probably fine, but if you want to be 100% paranoid, the safest
thing to do is to leave it variadic but document that the variadic
arguments are useless.


> 2) If/when we decide that it is useful to pass extra information, we
> design that as a new function. I can't see a need for that in a
> cache-coherent system, and in a non-coherent system the interface needs to
> be more complicated than just a set of pointers (because you also need to
> know how big the object at the target of the pointer is). So this gets
> complicated, but, since we're not going to implement it until we need it
> and understand the problem better, that’s fine.


> I'm avoiding your #2 because I don't believe it is sufficient.
>

I'm fine with that decision; it's your call.  I hadn't looked to see what
these pointers were supposed to be; I guess I was assuming that they were
variable descriptors or something, not literally just pointers to objects
of unknown size.

It sounds like the flush operation is really designed for the benefit of
OpenMP implementations that aren't just using CPU threads.  Given that your
runtime's API is really only designed to be good enough for CPU threads,
there's no reason to future proof it, because current CPUs don't let us do
efficient partial memory barriers anyway.  If somebody comes out with a CPU
that does, we can embellish the API then.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141125/56b93729/attachment.html>