JF Bastien via llvm-dev
2019-Apr-17 16:35 UTC
[llvm-dev] 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/storeThis 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>
Jameson Nash via llvm-dev
2019-Apr-17 16:53 UTC
[llvm-dev] Disable combining of loads and stores in instcombine
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>
Neil Ryan via llvm-dev
2019-Apr-17 17:00 UTC
[llvm-dev] 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>
JF Bastien via llvm-dev
2019-Apr-17 17:01 UTC
[llvm-dev] Disable combining of loads and stores in instcombine
> 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>
Amara Emerson via llvm-dev
2019-Apr-17 17:42 UTC
[llvm-dev] Disable combining of loads and stores in instcombine
> 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>
JF Bastien via llvm-dev
2019-Apr-17 17:44 UTC
[llvm-dev] Disable combining of loads and stores in instcombine
> 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>