[LLVMdev] n-bit bytes for clang/llvm

Patrik Hägglund H
Wed, 18 Mar 2015 07:52:50 -0000

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>