[llvm-dev] Disable combining of loads and stores in instcombine
Jameson Nash via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 17 09:53:49 PDT 2019
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>
More information about the llvm-dev
mailing list