[LLVMdev] n-bit bytes for clang/llvm

Reid Kleckner rnk at google.com
Tue Mar 10 09:09:18 PDT 2015

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>

> 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>

More information about the llvm-dev mailing list