[llvm-dev] Disable combining of loads and stores in instcombine

JF Bastien via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 17 09:35:19 PDT 2019

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

More information about the llvm-dev mailing list