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

jingu kang via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 29 21:49:12 PST 2016


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


More information about the llvm-dev mailing list