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

[Sanjay Patel via llvm-dev]

Step back: where exactly in instcombine is this load/store combining
happening? I thought we don't do that for precisely the reasons stated in
this thread.

We used to have a dedicated IR pass for load combining that was removed:
https://reviews.llvm.org/rL306067

We definitely do some load/store combining in SelectionDAG, but that should
all be preventable using target hooks.

AFAICT, the place this happens in IR is the -memcpyopt pass? If that's the
problem, then how about adding a TargetTransformInfo dependence/hook there
to stop this transform?



On Fri, Apr 19, 2019 at 2:54 PM Neil Ryan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Sorry, I meant that if I have a series of character loads that get
> combined into a single word load, I don’t know of a way to 1) know that the
> word load was originally comprised of character loads and 2) decompose the
> word load back into character loads.
> Granted, if I have (1), (2) just a matter of inserting the right ops. I’ve
> been digging into MachineMemOperand — I’m not entirely sure what methods in
> this class can get me this information. Any pointers would be much
> appreciated.
>
> Neil
> On Apr 18, 2019, 1:45 PM -0700, Arsenault, Matthew <
> Matthew.Arsenault at amd.com>, wrote:
>
> I’m not sure what you mean by this. The type in memory doesn’t really mean
> anything, and no information is lost. You can still tell (for
> optimizations) some information about the underlying IR object from the
> MachineMemOperand, which is mostly used for alias analysis.
>
>
>
> -Matt
>
>
>
> *From:* Neil Ryan <neilryan at cs.washington.edu>
> *Date:* Thursday, April 18, 2019 at 9:59 PM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>, "tstellar at redhat.com" <
> tstellar at redhat.com>, "Arsenault, Matthew" <Matthew.Arsenault at amd.com>
> *Subject:* Re: [llvm-dev] Disable combining of loads and stores in
> instcombine
>
>
>
> 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
>
>
>
> _______________________________________________
> 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/20190421/1e7dcc40/attachment.html>