llvm dev - Jun 2018 - accessing subwords in memory

I'm targeting a machine that can only load and store aligned 64-bit words,
but I'd like to be able to pack 8-, 16-, and 32-bit values into these words.
Loads will require various shifts and masks; stores are more complicated.
Does LLVM provide any support for such things?
Is there an example target I can look at for ideas?

Thanks,
Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180626/21ce8947/attachment.html>

On 06/26/2018 12:06 PM, Preston Briggs via llvm-dev
wrote:
> I'm targeting a machine that can only load and store aligned 64-bit
words,
> but I'd like to be able to pack 8-, 16-, and 32-bit values into these
words.
> Loads will require various shifts and masks; stores are more complicated.
> Does LLVM provide any support for such things?
> Is there an example target I can look at for ideas?
> 
The R600 subtarget in the AMDGPU backend does this with loads/stores for some
address spaces.  See R600TargetLowering::lowerPrivateExtLoad()
and R600TargetLowering::lowerPrivateTruncStore().

-Tom
> Thanks,
> Preston
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> I'm targeting a machine that can only load and store aligned 64-bit
words,
Does this imply that the target uses word addresses instead of byte addresses?

Boris

On Wed, Jun 27, 2018 at 12:32 AM, Boris Boesler <baembel at gmx.de>
wrote:
> > I'm targeting a machine that can only load and store aligned
64-bit
words,
>
> Does this imply that the target uses word addresses instead of byte
addresses?

The machine uses byte addresses, but lacks instructions to do things like
load/store byte.
So we must load a word, then find the desired byte.

Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180627/8aaebc8a/attachment.html>