<div dir="ltr">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?" <div><br></div><div>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. <br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 11, 2015 at 9:37 AM, Patrik Hägglund H <span dir="ltr"><<a href="mailto:patrik.h.hagglund@ericsson.com" target="_blank">patrik.h.hagglund@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It's definitely doable, but I'd be worried about the maintenance burden.<br>
<br>
</span>Yes, that is a problem.<br>
<br>
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.<br>
<br>
/Patrik Hägglund<br>
<br>
From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On Behalf Of Reid Kleckner<br>
Sent: den 10 mars 2015 17:09<br>
To: Tyro Software<br>
Cc: LLVM Developers Mailing List<br>
<span class="im HOEnZb">Subject: Re: [LLVMdev] n-bit bytes for clang/llvm<br>
<br>
</span><div class="HOEnZb"><div class="h5">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.<br>
<br>
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.<br>
<br>
On Tue, Mar 10, 2015 at 3:12 AM, Tyro Software <<a href="mailto:softwaretyro@gmail.com">softwaretyro@gmail.com</a>> wrote:<br>
Back in 2009 there was some discussion of the practicality of supporting char sizes greater than 8-bit:<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349</a><br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025</a><br>
<br>
with the consensus seemingly being "quite doable, please get a good patch and submit".<br>
<br>
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:<br>
<br>
/// isString - This method returns true if this is an array of i8.<br>
bool ConstantDataSequential::isString() const {<br>
  return isa<ArrayType>(getType()) && getElementType()->isIntegerTy(8);<br>
}<br>
<br>
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?<br>
<br>
Thanks for whatever advice & thread necromancy you can offer,<br>
Tyro<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</div></div></blockquote></div><br></div>