rjmccall added a comment.

In D79279#2170187 <https://reviews.llvm.org/D79279#2170187>, @jfb wrote:

> In D79279#2170157 <https://reviews.llvm.org/D79279#2170157>, @rjmccall wrote:
>
> > I think the argument is treated as if it were 1 if not given.  That's all 
> > that ordinary memcpy formally guarantees, which seems to work fine 
> > (semantically, if not performance-wise) for pretty much everything today.
>
>
> I'm not sure that's true: consider a `memcpy` implementation which copies 
> some bytes twice (at different access size, there's an overlap because 
> somehow it's more efficient). That would probably violate the programmer's 
> expectations, and I don't think `volatile` nor atomic `memcpy` allow this 
> (but regular `memcpy` does).


Yes, that's true, if you need an only-accessed-once guarantee, that's above and 
beyond just a minimum access size.  I agree that `volatile` would need to make 
this guarantee.

>> Do you think it'd be useful to have different guarantees for different 
>> operands?  I guess it could come up, but it'd be a whole lot of extra 
>> complexity that I can't imagine we'd ever support.
> 
> You mean, if `element_size` is passed then you get different guarantees?

No, sorry, I mean different guarantees for the different pointer operands.  In 
principle, we could allow you to say that the memcpy has to be done with 4-byte 
accesses from the source and 2-byte accesses to the destination.  That's 
implementable but a lot of work.

>> If one of the arguments is `volatile`, arguably the minimum access width (if 
>> given) needs to be exact.  If we don't support that right now, it's okay to 
>> make it an error, which is basically you've already done with the `_Atomic 
>> volatile` diagnostic.
> 
> Agreed. `volatile` with size makes a lot of sense, and the IR version of it, 
> once created, ought to not be able to widen accesses. `volatile` without a 
> size specified makes sense too, because you just want a single read and a 
> single write, don't care about tearing.

Right.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79279/new/

https://reviews.llvm.org/D79279



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to