[llvm-dev] Question about store with unaligned memory address

[Bruce Hoult via llvm-dev]

Sorry .. *two* elt loads, one elt store, and an aligned vector store.


On Tue, Feb 2, 2016 at 3:30 PM, Bruce Hoult <bruce at hoult.org> wrote:

> I'm afraid I'm not yet skilled with LLVL IR, but I think you'd probably
> want to do something like this:
>
> #include <stdint.h>
>
> typedef uint32_t elt;
> typedef elt v4 __attribute__ ((vector_size (16)));
>
> void store(v4 *p, v4 v){
>   uintptr_t align = uintptr_t(p) & (sizeof(elt)-1);
>   if (align == 0){
>     *p = v;
>   } else {
>     // assert sizeof(elt) == 4
>     // assert align == 2
>     elt *base = (elt*)(uintptr_t(p) - 2);
>     elt lomask = (1<<16)-1;
>     elt himask = ~lomask;
>     base[0] = (base[0] & lomask) | v[0] << 16;
>     base[1] = v[0] >> 16 | v[1] << 16;
>     base[2] = v[1] >> 16 | v[2] << 16;
>     base[3] = v[2] >> 16 | v[3] << 16;
>     base[4] = v[3] >> 16 | (base[4] & himask);
>   }
> }
>
> Of course you'll want to convert one LLVM IR to another, not actually
> insert C code, but you can compile this code and see what IR is produced.
>
> Interestingly, LLVM manages to optimize this to one elt load, one elt
> store, and an aligned vector store. Plus some in-registers shuffling, of
> course.
>
>
> On Mon, Feb 1, 2016 at 5:49 PM, jingu kang <jaykang10 at gmail.com> wrote:
>
>> Hi Bruce,
>>
>> Thanks for response.
>>
>> I also think it is not good way. Do you have the other ways to legalize
>> it?
>>
>> Thanks,
>> JinGu Kang
>>
>> 2016-02-01 13:11 GMT+00:00 Bruce Hoult <bruce at hoult.org>:
>> > In fact this is a pretty bad legalizing/lowering because you only need
>> to
>> > load and edit for the first and last values in the vector. The other
>> words
>> > are completely replaced and don't need to be loaded at all.
>> >
>> > I think you need to legalize differently when it is not aligned.
>> >
>> > On Fri, Jan 29, 2016 at 10:07 PM, jingu kang via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> Hi Krzysztof,
>> >>
>> >> Thanks for response.
>> >>
>> >> The method is working almost of test cases which use load and store
>> >> instructions connected with chain. There is other situation. Let's
>> >> look at a example as follows:
>> >>
>> >> typedef unsigned short int UV __attribute__((vector_size (8)));
>> >>
>> >> void test (UV *x, UV *y) {
>> >>   *x = *y / ((UV) { 4, 4, 4, 4 });
>> >>  }
>> >>
>> >> The target does not support vector type so CodeGen tries to split and
>> >> scalarize vector to legalize type. While legalizing vector type, the
>> >> stores of each vector elements nodes are generated from
>> >> 'DAGTypeLegalizer::SplitVecOp_STORE'. But the stores are not connected
>> >> with chain. I guess it assumes each vector element's address is
>> >> different. The each store is lowered to load and store nodes with high
>> >> and low address but they are not connected with the other store's one.
>> >> It causes problem. I am not sure how to solve this situation
>> >> correctly.
>> >>
>> >> Thanks,
>> >> JinGu Kang
>> >>
>> >>
>> >> 2016-01-29 18:11 GMT+00:00 Krzysztof Parzyszek via llvm-dev
>> >> <llvm-dev at lists.llvm.org>:
>> >> > On 1/29/2016 10:47 AM, JinGu Kang via llvm-dev wrote:
>> >> >>
>> >> >>
>> >> >> I am doing it with lowering store as follow:
>> >> >>
>> >> >> 1. make low and high address with alignment.
>> >> >> 2. load 2 words from low and high address.
>> >> >> 3. manipulate them with values to store according to alignment.
>> >> >> 4. store 2 words modified to low and high address
>> >> >
>> >> >
>> >> > Sounds ok.
>> >> >
>> >> >
>> >> >> In order to keep the order between loads and stores, I have used
>> chain
>> >> >> and
>> >> >> glue on the DAG but some passes have mixed it in machine instruction
>> >> >> level.
>> >> >
>> >> >
>> >> > Glue isn't necessary, chains are sufficient.
>> >> >
>> >> > I'm not sure what pass reordered dependent loads and stores, but that
>> >> > sounds
>> >> > bad.  What matters in cases like this are the MachineMemOperands.  If
>> >> > there
>> >> > isn't any on a load/store instruction, it should be treated
>> >> > conservatively
>> >> > (i.e. alias everything else), if there is one, it'd better be
>> correct.
>> >> > Wrong MMO could certainly lead to such behavior.
>> >> >
>> >> > -Krzysztof
>> >> >
>> >> >
>> >> > --
>> >> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> >> > hosted by
>> >> > The Linux Foundation
>> >> >
>> >> > _______________________________________________
>> >> > LLVM Developers mailing list
>> >> > llvm-dev at lists.llvm.org
>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> >
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/871e200e/attachment-0001.html>