[LLVMdev] n-bit bytes for clang/llvm

Tyro Software softwaretyro at gmail.com
Tue Mar 17 04:11:08 PDT 2015


As an alternative to fixing the "char == 8 bits" presumption would using
non-uniform pointer types have been another possible approach, e.g. keep
char as 8 bit but have char* encode both the word address and the byte
location within it (i.e. one extra bit in this 16-bit case). Of course this
is only a less intrusive (to LLVM) approach if LLVM readily supports such
pointers, which may be close to asking "could 8086 small/large/huge
pointers be implemented?"

One obvious drawback to such an approach is that dereferencing char*
becomes relatively expensive, though for the sort of code being
predominantly run on a DSP that might be acceptable.



On Wed, Mar 11, 2015 at 9:37 AM, Patrik Hägglund H <
patrik.h.hagglund at ericsson.com> wrote:

> > It's definitely doable, but I'd be worried about the maintenance burden.
>
> Yes, that is a problem.
>
> We are currently not allowed to reveal our target (which has 16-bit bytes,
> and registers with non-power-of-two bit widths) fully, and therefore not
> able to submit it upstream. One idea we have toyed with is to create a
> simple "dummy" version of our target, just to be able complement patches
> with tests. For 16-bit byte support we may also pick some existing simple
> architecture, such as DCPU-16 or TI C54x. One other idea is just to have
> the changes on a branch upstream.
>
> /Patrik Hägglund
>
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
> Behalf Of Reid Kleckner
> Sent: den 10 mars 2015 17:09
> To: Tyro Software
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] n-bit bytes for clang/llvm
>
> It's definitely doable, but I'd be worried about the maintenance burden.
> Beyond contributing the initial patches, I'd want to see a maintenance
> commitment and relatively comprehensive tests that can be run upstream.
>
> For example, if there were an i24 MVT, how would I test my target
> independent SDAG change that operates on all integer values? Currently, our
> answer to that question is "find a backend that uses it and test that".
> Without such a backend, it's hard for us to promise that this support will
> continue to work.
>
> On Tue, Mar 10, 2015 at 3:12 AM, Tyro Software <softwaretyro at gmail.com>
> wrote:
> Back in 2009 there was some discussion of the practicality of supporting
> char sizes greater than 8-bit:
>
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025
>
> with the consensus seemingly being "quite doable, please get a good patch
> and submit".
>
> However the current code appears (to my neophyte eyes) to be explicitly
> 8-bit, e.g. one instance called out in the mail thread remains:
>
> /// isString - This method returns true if this is an array of i8.
> bool ConstantDataSequential::isString() const {
>   return isa<ArrayType>(getType()) && getElementType()->isIntegerTy(8);
> }
>
> I didn't find anything related beyond this mail thread such as a
> discussion of a patch but of course I might be searching too narrowly -
> perhaps someone here can recall whether it went any further, whether
> insurmountable barriers do exist, etc?
>
> Thanks for whatever advice & thread necromancy you can offer,
> Tyro
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150317/d20657e1/attachment.html>


More information about the llvm-dev mailing list