[LLVMdev] non-standard machine value types

[Volodymyr Arbatov]

Users can extend our architecture with own register files and own
instructions. They are not limited to a narrow set of bit widths. I think,
to support such extensions, I'll need to handle MVTs dynamically. Perhaps,
use standard MVTs whenever is possible and reserve a range for extensions.

Still, it's interesting to see your set of 24/40-bit MVTs related patches,
this might be a good example on how to extend MVTs. Is it publicly
available?

Thanks,
Volodymyr.


On Wed, Jun 10, 2015 at 12:32 AM, Patrik Hägglund H <
patrik.h.hagglund at ericsson.com> wrote:

>  We maintain a set of patches for enabling 24/40-bit MVTs, and also a set
> of patches to support 16-bit bytes. I can provide them upon request. (Only
> llvm, no clang patches yet.)
>
>
>
> /Patrik Hägglund
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Matt Arsenault
> *Sent:* den 4 juni 2015 09:07
> *To:* Volodymyr Arbatov
> *Cc:* llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] non-standard machine value types
>
>
>
>
>
>  On Jun 3, 2015, at 11:48 PM, Volodymyr Arbatov <gm.ivlad at gmail.com>
> wrote:
>
>
>
> Hi all.
>
>
>
> I'm looking for a ways of defining register files with non-standard
> machine value type in tablegen. The value types not covered by
> SimpleValueType enum. For example (from the top of my head) 25 bit
> integers, or 8 way 18 bit integers. These types going to be used with
> intrinsics so I also need appropriate C custom types defined.
>
>
>
> I wonder if I can describe those in tablegen files or do I need to extend
> llvm. What is the right way of supporting such types?
>
>
>
> I'm not familiar will llvm internals so far, so any help and pointers
> appreciated.
>
>
>
> Thanks,
>
> Volodymyr.
>
> ___________________
>
>
>
> You would need an MVT type defined for every legal type you have, so you
> would need to add those. However, LLVM has a pretty widely spread
> assumption of 8-bit bytes, so that will be far more problematic for your
> target. Fixing that would be a large project.
>
>
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150611/e960a1d6/attachment.html>