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



On Fri, Sep 15, 2017 at 6:55 PM, Friedman, Eli <efriedma at codeaurora.org>

> 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