[ofiwg] allowing aliasing in fetch atomics?

[Jeff Hammond]

Sure, and every C compiler out there can do multiple version code
generation such that no code should ever show a benefit with restrict.

The fundamental idea here is that allowing aliasing is a bad semantic and
there should be a compelling reason for supporting it.  The higher level
models that informed the design of OFI either explicitly prohibit aliasing
(MPI RMA and UPC) or their APIs make it impossible (SHMEM).

If there is client that requires this semantic, I'd like to understand why
it is permitted to burden OFI rather than requiring that client to do its
own buffering.

I am still investing Jianxin's comment on the ticket wherein MPI was
affected by this.  I do not understand how a correct MPI program would
encounter an issue here.

Jeff

On Wed, Nov 11, 2015 at 11:34 AM, Dave Goodell (dgoodell) <
dgoodell at cisco.com> wrote:

> On Nov 11, 2015, at 2:01 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
> >
> > Why do memcpy and memmove both exist?  Why did C99 introduce restrict?
> Why does Fortran prohibit aliasing?
> >
> > I have measured the benefits of restrict semantics w.r.t. vectorization
> many times in the past, enough that I did not bother to benchmark this
> specific case.
>
> But you already offered a fix for that issue, which was to just have two
> versions of the implementation to handle aliased/non-aliased.  The overlap
> check is pretty cheap.
>
> -Dave
>
>


-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20151111/c3a611bb/attachment.html>