llvm dev - Feb 2016 - Question about store with unaligned memory address

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

I'm not clear, but it sounds like maybe your issue is not just alignment,
but that you have no 1/2-byte load or store operations at all on your
target?

Do you mean that to do any 2-byte store, even if it's naturally aligned,
you need to load the 4-byte word that contains it, replace the low or high
half as appropriate, and then use a 4-byte store to store back the modified
value?

On Fri, Jan 29, 2016 at 2: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160130/97a4a74b/attachment.html>

I think I need to explain the situation more. There is a example from
previous example.

Source code:
typedef unsigned short int UV __attribute__((vector_size (8)));

void test (UV *x, UV *y) {
  *x = *y / ((UV) { 4, 4, 4, 4 });
}

IR snippet from "*x = ...":
...
  %div = udiv <4 x i16> %1, %2
  %3 = load <4 x i16>*, <4 x i16>** %x.addr, align 4
  store <4 x i16> %div, <4 x i16>* %3, align 8
...

Selection Dag before type legalize:
...
  0x85ceac8: i32,ch = load 0x85ced18, 0x85cf1b8,
0x85c8e20<LD4[%x.addr]> [ORD=12]
...
        0x85d3a28: v4i16 = srl 0x85d51a0, 0x85c79d0 [ORD=11] <-- from udiv
      0x85c8aa8: ch = store 0x85ceac8:1, 0x85d3a28, 0x85ceac8,
0x85c8e20<ST8[%3]> [ORD=13]
...

Selection Dag after type legalize:
...
0x85ceac8: i32,ch = load 0x85d0798, 0x85cf1b8, 0x85c8e20<LD4[%x.addr]>
[ORD=12] [ID=-3]
...
          0x85dc2a8: ch = store 0x85ceac8:1, 0x85d18c8, 0x85ceac8,
0x85c8e20<ST2[%3](align=8), trunc to i16> [ORD=13] [ID=-3]
...
          0x85dc058: ch = store 0x85ceac8:1, 0x85c8cf8, 0x85dbab0,
0x85c8e20<ST2[%3(align=8)+2](align=2), trunc to i16> [ORD=13] [ID=-3]
...
          0x85db860: ch = store 0x85ceac8:1, 0x85d2fc0, 0x85dacd0,
0x85c8e20<ST2[%3(align=8)+4](align=4), trunc to i16> [ORD=13] [ID=-3]
...
         0x85db610: ch = store 0x85ceac8:1, 0x85d09e8, 0x85db170,
0x85c8e20<ST2[%3(align=8)+6](align=2), trunc to i16> [ORD=13] [ID=-3]
...

The vector type operations are scalarized because the target does not
support vector type like above selection dag. The scalarized each
store has the same chain from load:0x85ceac8 because it assumes they
access different address. As I said on first e-mail, I lower the each
store to 2 load and 2 store nodes for 2 words with high and low
address and the address could be same between adjacent vector
element's stores. In SelectionDAG stage, I have tried to keep the
order of load and store nodes with chain and glue while I lowering the
each element's store. But, In machine IR stage, it is broken because
they are not dependent each other and could access same address. One
vector element's load and store could interfere between the other's
load and store. If I try to use the 2 words way, I need to keep the
each vector element's store as one chunk. But I am not sure whether it
is good way or not... If someone has experience with this kind of
situation, please give me any comment. It will be very helpful.

Thanks,
JInGu Kang

2016-01-29 19:07 GMT+00:00 jingu kang <jaykang10 at
gmail.com>:
> 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

Hi James,

Thanks for response.
> you have no 1/2-byte load or store operations at all on your target?
Yep, it only has 4 byte load and store.
> even if it's naturally aligned, you need to load the 4-byte word that
contains it, replace the low or high half as appropriate, and then use a 4-byte
store to store back the modified value?
Yep, I am doing it.

I have written the situation a little bit more with selection dag
snippet a short time ago. Please reference it.

Thanks,
JinGu Kang


2016-01-30 5:29 GMT+00:00 James Y Knight <jyknight at
google.com>:
> I'm not clear, but it sounds like maybe your issue is not just
alignment,
> but that you have no 1/2-byte load or store operations at all on your
> target?
>
> Do you mean that to do any 2-byte store, even if it's naturally
aligned, you
> need to load the 4-byte word that contains it, replace the low or high half
> as appropriate, and then use a 4-byte store to store back the modified
> value?
>
> On Fri, Jan 29, 2016 at 2: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
>
>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/a63e0334/attachment.html>

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