[cfe-dev] [RFC] volatile mem* builtins

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Thu May 7 15:07:25 PDT 2020


Volatile memcpy/memset/etc are indeed rather underspecified. As LangRef
states, "If the isvolatile parameter is true, the llvm.memcpy call is a
volatile operation. The detailed access behavior is not very cleanly
specified and it is unwise to depend on it."

I think the intent at the moment is that the mem-operation as a whole
should be treated as volatile -- so the memory copy, as a whole, will
happen only once -- but that there's no guarantee as to what loads/stores
are used to implement that, including potentially reading/writing some
bytes multiple times, with different access sizes. I think those semantics
make sense, but really ought to be fully nailed down.




On Thu, May 7, 2020 at 5:13 PM Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, May 06, 2020 at 03:40:43PM -0700, JF Bastien via cfe-dev wrote:
> > I’d like to add volatile overloads to mem* builtins, and authored a
> patch: https://reviews.llvm.org/D79279 <https://reviews.llvm.org/D79279>
>
> The major issue I have here is that it seems to seriously underspecify
> what it is actually happening with the memory. Consider an
> implementation of memset for example. It is entirely legal and
> potentially even useful to check for length being >= two registers and
> in that case implement it as
>     write to [start, start+reglen)
>     write to [start+len-reglen,start+len)
>     write to (start+reglen)&(reglen-1) in reglen blocks until reaching
>     the end
>
> or variations to try to hide the unaligned head and tail case in the
> main loop. This would violate the normal assumptions around volatile,
> e.g. when using device memory.
>
> Joerg
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200507/d6e4cbf4/attachment.html>


More information about the cfe-dev mailing list