[LLVMdev] n-bit bytes for clang/llvm

[Hal Finkel]

----- Original Message -----
> From: "Tyro Software" <softwaretyro at gmail.com>
> To: "Reid Kleckner" <rnk at google.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Wednesday, March 11, 2015 3:50:45 AM
> Subject: Re: [LLVMdev] n-bit bytes for clang/llvm
> 
> 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.
> 

Generically speaking, we'd like to have a mock target for testing purposes (see this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083085.html). It could be used for this purpose.

 -Hal

> 
> 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
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory