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

[Neil Ryan via llvm-dev]

IIRC it’s not strictly possible to determine what array a load/store is based on. I don’t believe the decomposition is always possible, as information is lost when accesses are combined.

Neil
On Apr 17, 2019, 12:31 PM -0700, Arsenault, Matthew <Matthew.Arsenault at amd.com>, wrote:
> This is really a codegen problem. You can decompose the load/store however you like in the backend. InstCombine should still combine the loads as a canonicalization.
>
> -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: Wednesday, April 17, 2019 at 9:28 PM
> To: llvm-dev <llvm-dev at lists.llvm.org>, "tstellar at redhat.com" <tstellar at redhat.com>
> Subject: Re: [llvm-dev] Disable combining of loads and stores in instcombine
>
> I’m writing a pass for some custom hardware — we’d like to split arrays across hardware elements; this doesn’t work if consecutive writes to characters get combined to a word.
> On Apr 16, 2019, 8:17 PM -0700, Tom Stellard <tstellar at redhat.com>, wrote:
>
> > On 04/16/2019 11:38 AM, Neil Ryan via llvm-dev wrote:
> >
> > > 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?
> >
> > Why do you want to disable this optimization?
> >
> > -Tom
> >
> >
> >
> > > 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/20190418/440559e2/attachment.html>