[LLVMdev] n-bit bytes for clang/llvm

[Tyro Software]

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>