[PATCH] [PATCH][SROA]Also slice the STORE when slicing a LOAD in AllocaSliceRewriter

[Chandler Carruth]

On Mon, Aug 25, 2014 at 7:50 PM, Hao Liu <Hao.Liu at arm.com> wrote:

> Example for the specific case @load_store_i64 in the patch. There is an
> i64 alloca, then the alloca is stored by two i32 STOREs. Following is the
> i64 LOAD. Currently, the SROA splits the i64 LOAD, so that  the former two
> i32 STOREs and the i64 LOAD can be optimized and removed.
> The problem is that the split of i64 LOAD introducing additional
> ZEXT/SHL/AND/OR IRs to handle the following i64 uses. Such additional IRs
> try to combine two i32 into one i64 and then store it. So I think why don't
> we store two i32 separately so that such additional IRs can be removed.
> I add patch in SROA, because following 3 reasons:
>   1) It is SROA that introduces such additional IRs.
>   2) Also it is easier to do such optimize in SROA. The LOAD can be sliced
> means the STORE also can be sliced. We can just split the STORE. If we keep
> such additional IRs and i64 STORE, the following optimizer or backend
> optimizer need more efforts to analyze both such additional IRs and STORE.
> Currently we don't have such similar optimization.
>

These are reasons why *if* this is the right thing to do, it would be
reasonable to do it in SROA. The question is -- should we be splitting the
stores up at all, and why?

I don't believe we should. I'll reply to your other email with the details
of why I think this is the case.


>   3) This patch does the same thing as SROA handles memory copy.
>

Note that this is pretty much incidental. It wasn't my intent to handle
memcpy differently, it was just convenient at the time. It would probably
be better for it to do two loads, combine the bits, and the store once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140829/e414c7a7/attachment.html>