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

> 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
<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
> 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/ae24e187/attachment.html>

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
>
<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
> 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/6bce2521/attachment.html>

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 9:53 AM, 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.
“Should” and “target-legal” aren’t very good promises :-)
The “must not” bit is interesting, I hadn’t noticed it!

In any case, I agree that LLVM should do what it can to meet expectations w.r.t.
volatile, and in this case avoid merging when it can (i.e. only merge if there
are no corresponding memory operations).

> 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/7581cdf3/attachment-0001.html>

> On Apr 17, 2019, at 9:35 AM, 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 <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.
Is this really true? The writes to two volatile variables are sequenced and
can’t be re-ordered since they can have side effects, and so merging adjacent
volatile stores would break this.
> 
> 
>>  -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/7fcc1068/attachment.html>

> On Apr 17, 2019, at 10:42 AM, Amara Emerson <aemerson at apple.com>
wrote:
> 
> 
> 
>> On Apr 17, 2019, at 9:35 AM, 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.
> Is this really true? The writes to two volatile variables are sequenced and
can’t be re-ordered since they can have side effects, and so merging adjacent
volatile stores would break this.
There’s further discussion of what we promise downthread. It’s definitely true
of C / C++, a handwavy promise in LLVM LangRef, and the LLVM memory model just
says “same as C / C++".

>>>  -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/76fe1d4d/attachment-0001.html>