[llvm-dev] What should a truncating store do?
Jon Chesterfield via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 15 11:30:20 PDT 2017
Interesting, thank you. I expected both answers to be "unchanged" so was
surprised by the zero extend in the legaliser.
The motivation here is that it's faster for us to load N bytes, apply
whatever masks are necessary to reproduce the truncating store then store
all N bytes. This is only a good plan if there's no change to the semantics
:)
Are scalar integer types zero extended to the next multiple of 8 or to the
next power of 2 greater than 7? For example, i17 => i24 or i17 => i32?
I think this means truncating stores of vector types will introduce zero
bits at the end of each element instead grouping all the zeros at the end.
For example, <i6 63, i6 63> writes to sixteen bits as 0b0011111100111111,
not as 0b0000111111111111?
Thanks!
Jon
On Fri, Sep 15, 2017 at 6:55 PM, Friedman, Eli <efriedma at codeaurora.org>
wrote:
> On 9/15/2017 5:49 AM, Jon Chesterfield via llvm-dev wrote:
>
>> For example, truncating store of an i32 to i6. My assumption was that
>> this should write the low six bits of the i32 to somewhere in memory.
>>
>> Should the top 24 bits of a corresponding 32 bit region of memory be
>> unchanged, zero, undefined?
>>
>
> Unchanged.
>
> Should the two bits that would round the i6 up to a byte be preserved,
>> zero, undefined?
>>
>
> Zero. Legalization will normally handle this for you, though, by
> transforming it to an i8 store.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/1b054776/attachment.html>
More information about the llvm-dev
mailing list