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

> 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>

> On Apr 17, 2019, at 10:40 AM, Neil Ryan <neilryan at
cs.washington.edu> wrote:
> 
> 
>> 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.
That does seem like a valid use case, albeit one that C / C++ and LLVM IR can’t
really help you with today. Volatile has the limitations you’ve described, and
relaxed atomics could be combined as you’d like to avoid (though they probably
won’t be right now).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/9a8693d7/attachment.html>