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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/6bf0691a/attachment.html>
As written in the threads shown below, we maintain LLVM patches for 16-bit
bytes.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076603.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083157.html
/Patrik Hägglund
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Tyro Software
Sent: den 10 mars 2015 11:12
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] n-bit bytes for clang/llvm
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
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/20150310/56e82ec9/attachment.html>
> 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
I agree with the sentiment: without a usable backend bit-rot will surely ensue. I guess ideally the patches would accompany a real backend relying upon them and a target environment executing them, e.g. a simulator environment for the DSP so access to the real hardware isn't required. FWIW my original curiosity stems from wondering whether a C/C++ compiler can even be created for a non-mainstream architecture such as Knuth's original MIX (http://en.wikipedia.org/wiki/MIX - given such features as a byte size that isn't aligned to the memory word size of 6-bit bytes, 31-bit words, so a char pointer effectively requires padding for the p[5] case of bit-30). But if a MIX backend was created then at least execution environments exist for it - however I guess a very real question for the community clang/llvm would be whether the additional complexity for supporting such a "toy environment" is warranted, especially since MIX was superseded by MMIX (which has a gcc backend). On Tue, Mar 10, 2015 at 5:09 PM, Reid Kleckner <rnk at google.com> wrote:> 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/20150311/fe277964/attachment.html>
Reasonably Related Threads
- [LLVMdev] n-bit bytes for clang/llvm
- [LLVMdev] n-bit bytes for clang/llvm
- [LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
- [LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
- [LLVMdev] Lost commit mails