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

Hi All,

I have a question about store with unaligned memory address.

I am working on target which has only 4 byte aligned load and store 
instruction and I am generating 2 load and store instructions to store 
value on memory which the address is not aligned 4. 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

There could be independent stores with same target memory address 
because it makes and accesses low and high address with lowering. 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. I am feeling above idea is not good... Do I need to use pseudo 
instruction? I am not sure which one is good idea... Could someone have 
experience with unaligned memory access? If I missed something, please 
let me know. It will be really helpful!!!

Thanks,
JinGu Kang

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

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