llvm dev - Apr 2019 - Disable combining of loads and stores in instcombine

> Why do you want this?
The goal is to share arrays between multiple tiles on a manycore architecture by
splitting arrays between tiles. With a DRF memory model, it makes sense to elide
multiple loads to the same memory location between barriers.; IIRC the semantics
for volatile don’t allow this eliding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/e6e6c004/attachment.html>

> On Apr 17, 2019, at 10:06 AM, Neil Ryan <neilryan at
cs.washington.edu> wrote:
> 
> 
>> Why do you want this?
> 
> 
> The goal is to share arrays between multiple tiles on a manycore
architecture by splitting arrays between tiles. With a DRF memory model, it
makes sense to elide multiple loads to the same memory location between
barriers.; IIRC the semantics for volatile don’t allow this eliding.
If there hasn’t been synchronization between to loads, then yes it makes sense
to elide loads in a DRF memory model.
Indeed volatile loads cannot be elided.
But why is it desirable to avoid combining adjacent stores? If you’ve got DRF
code then the combination can’t be observed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/b5d0ccb3/attachment.html>

> But why is it desirable to avoid combining adjacent stores? If you’ve got
DRF code then the combination can’t be observed.
It’s more that the consecutive stores would be going to different tiles. If
multiple stores are combined in IR, I don’t think they’d be able to decoupled in
IR, unless there’s a way to always determine which global object an arbitrary
GEP is pointing to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/7329cfea/attachment.html>