[LLVMdev] n-bit bytes for clang/llvm

[Patrik Hägglund H]

Hi Tyro,

You seems to suggest that one way to avoid the problem of implementing 16-bit bytes at the C level, would be to use 8-bit bytes instead. ;-) If the target has 16 bits as the addressable unit of storage, then byte pointers would be implemented as “fat pointers”. Yes, this would probably be possible. But we haven’t tried it, both because of backward compatibility concerns (for legacy C code), and because of the performance implications that you point out. (Our target also have 16-bit registers dedicated for pointers.)

/Patrik Hägglund

From: Tyro Software [mailto:softwaretyro at gmail.com]
Sent: den 17 mars 2015 12:11
To: Patrik Hägglund H
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] n-bit bytes for clang/llvm

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<mailto: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> [mailto: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<mailto: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<mailto: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/20150318/94e35b89/attachment.html>