> 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
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>
On 17 Mar 2015, at 13:11, Tyro Software <softwaretyro at gmail.com> wrote:> > 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.We're using multiple address spaces to describe two pointer representations for CHERI: AS0 is a 64-bit pointer that's represented as an integer, AS200 is a capability (256-bit fat pointer with base, length, permissions, enforced in hardware). We had to fix a few things where LLVM assumes that pointers are integers, but the different size pointers in different address spaces part works very well. The biggest weakness is in TableGen / SelectionDAG, where you can't write patterns on iPTR that depend on a specific AS (actually, you can't really write patterns on iPTR at all, as LLVM tries to lower iPTR to some integer type first, even when this doesn't make any sense [e.g. on an architecture with separate address and integer registers]). Having AS0 be a byte pointer, which the back end would lower to two words, and some target-specific AS be a word pointer would likely work quite well. David
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>
Apparently Analagous Threads
- [LLVMdev] n-bit bytes for clang/llvm
- [InstCombine] Addrspacecast and GEP assumed commutative
- [LLVMdev] n-bit bytes for clang/llvm
- [cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
- [cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang