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

So, volatile’s been a fine solution — the issue is volatile pointers would
perform the load every time; ideally memory accesses would be able to be cached.
This is why I’ve been leaning towards disabling the part of instcombine that
combines memory accesses instead of using volatile — there should be better
performance.
On Apr 17, 2019, 9:54 AM -0700, Jameson Nash <vtjnash at gmail.com>,
wrote:
> The lang ref promises that, "the backend should never ... merge
target-legal volatile load/store instructions". Which I've usually
assumed meant that it was promised? Just curious if you thought this left some
wiggle room for some optimizations, since my impression was that someone wanted
to let you know that it's dependable. Likewise, there's also the clause
that "The optimizers must not change the number of volatile
operations", which doesn't seem to explicitly forbid merging, but does
seem to me like it would make it difficult to find a case where it would be
profitable.
>
> > On Wed, Apr 17, 2019 at 12:35 PM JF Bastien via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> > >
> > > > On Apr 17, 2019, at 5:02 AM, Arsenault, Matthew via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > > >
> > > > This won’t happen with volatile load/store
> > >
> > > This is mostly true today, but AFAICT the LLVM memory model
doesn’t actually offer this guarantee. It merely says that LLVM treats volatile
like C / C++ treats volatile… which isn’t much of a guarantee because C / C++
volatile doesn’t normatively mean anything. Specifically, we cannot really honor
this when volatile bitfields are used for which memory operations don’t exist:
> > >
> > > > struct {
> > > >   volatile int a : 12;
> > > >   volatile int b : 4;
> > > > } s;
> > >
> > > As things stand, we haven’t promised that we won’t combine
adjacent volatile stores, and C / C++ certainly allow us to do so. I don’t think
it would be a good idea to do so, but we certainly could.
> > >
> > >
> > > >  -Matt
> > > >
> > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on
behalf of llvm-dev <llvm-dev at lists.llvm.org>
> > > > Reply-To: Neil Ryan <neilryan at cs.washington.edu>
> > > > Date: Tuesday, April 16, 2019 at 9:01 PM
> > > > To: llvm-dev <llvm-dev at lists.llvm.org>
> > > > Subject: [llvm-dev] Disable combining of loads and stores in
instcombine
> > > >
> > > >  LLVM's optimizer combines stores to consecutive
characters into a write of a single word.  For instance, if I have char A[4] and
I write some static value to each element, these writes would be combined into a
single 32-bit word write. I found this thread from 2009 -- it seems like it
wasn't possible then. Has anything changed since?
> > > >
> > > > Neil
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > llvm-dev at lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/620c4d65/attachment.html>

> On Apr 17, 2019, at 10:00 AM, Neil Ryan <neilryan at
cs.washington.edu> wrote:
> 
> So, volatile’s been a fine solution — the issue is volatile pointers would
perform the load every time; ideally memory accesses would be able to be cached.
This is why I’ve been leaning towards disabling the part of instcombine that
combines memory accesses instead of using volatile — there should be better
performance.
Why do you want this?

> On Apr 17, 2019, 9:54 AM -0700, Jameson Nash <vtjnash at gmail.com>,
wrote:
>> The lang ref promises that, "the backend should never ... merge
target-legal volatile load/store instructions". Which I've usually
assumed meant that it was promised? Just curious if you thought this left some
wiggle room for some optimizations, since my impression was that someone wanted
to let you know that it's dependable. Likewise, there's also the clause
that "The optimizers must not change the number of volatile
operations", which doesn't seem to explicitly forbid merging, but does
seem to me like it would make it difficult to find a case where it would be
profitable.
>> 
>> On Wed, Apr 17, 2019 at 12:35 PM JF Bastien via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>>> On Apr 17, 2019, at 5:02 AM, Arsenault, Matthew via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> 
>>> This won’t happen with volatile load/store
>> 
>> This is mostly true today, but AFAICT the LLVM memory model doesn’t
actually offer this guarantee. It merely says that LLVM treats volatile like C /
C++ treats volatile… which isn’t much of a guarantee because C / C++ volatile
doesn’t normatively mean anything. Specifically, we cannot really honor this
when volatile bitfields are used for which memory operations don’t exist:
>> 
>> struct {
>>   volatile int a : 12;
>>   volatile int b : 4;
>> } s;
>> 
>> As things stand, we haven’t promised that we won’t combine adjacent
volatile stores, and C / C++ certainly allow us to do so. I don’t think it would
be a good idea to do so, but we certainly could.
>> 
>> 
>>>  -Matt 
>>>  
>>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
>>> Reply-To: Neil Ryan <neilryan at cs.washington.edu
<mailto:neilryan at cs.washington.edu>>
>>> Date: Tuesday, April 16, 2019 at 9:01 PM
>>> To: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>>> Subject: [llvm-dev] Disable combining of loads and stores in
instcombine
>>>  
>>>  LLVM's optimizer combines stores to consecutive characters
into a write of a single word.  For instance, if I have char A[4] and I write
some static value to each element, these writes would be combined into a single
32-bit word write. I found this thread
<http://llvm.1065342.n5.nabble.com/disabling-combining-load-stores-in-optimizer-td37560.html>
from 2009 -- it seems like it wasn't possible then. Has anything changed
since?
>>> 
>>> Neil
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190417/65139d09/attachment.html>

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