[ofiwg] allowing aliasing in fetch atomics?

[Jeff Hammond]

This comment is inspired by discussion on
https://github.com/ofiwg/libfabric/pull/1436.

According to the signature, the input argument (buf) is 'const void *' (the
output is 'void *').

ssize_t fi_fetch_atomic(struct fid_ep *ep, const void *buf,
	size_t count, void *desc, void *result, void *result_desc,
	fi_addr_t dest_addr, uint64_t addr, uint64_t key,
	enum fi_datatype datatype, enum fi_op op, void *context);


I'm sure it's valid C and I appreciate that restrict isn't there for a
reason, but it is nonetheless gross to update buf when it is a const
pointer when the underlying data is aliased by result.  Of course the user
should no better, but why design an API like this?

Is there a reason why buf and result can't be restrict pointers?  I see
zero value in enabling the case of aliased local buffers when the side
effects are (1) a const buffer is modified and (2) the potential code
optimization demonstrated in my pull request is disallowed (without
specializing the macro for the aliased and non-aliased cases, of course).

Note that MPI does not allow aliasing here: "The origin and result buffers
(origin_addr and result_addr) must be disjoint."  UPC uses restrict
extensively, so I doubt this is possible there.  OpenSHMEM cannot have this
usage since the result is the return value of the function, meaning it is
going to be allocated in an automatic variable inside of the function.

Jeff

-- 
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/0abdbd3b/attachment.html>