[LLVMdev] [cfe-dev] thoughts about n-bit bytes for clang/llvm

Ray Fix rayfix.ml at gmail.com
Wed Sep 23 16:15:53 PDT 2009


I am trying to gauge how much interest there is in supporting non-8- 
bit byte targets.

Other than myself, Ken Dyck of ON Semiconductor has a 24-bit machine  
he is trying to support.   We have been working jointly on this but we  
are also both new to Clang and LLVM.    Although both of our  
processors are not mainstream,  Ken points out that Texas Instruments  
the C5000 series is also 16-bit architecture.  I played around with  
TI's development environment today, and sure enough, it is perfectly  
valid to do:

        char foo = 32000;

It would be fairly easy to go through the LLVM/Clang code and change  
8s to 16s, fork it, and be done with it.  But I hoped we could fix it  
in a more general way that would be useful to others.  As Mike Stump  
suggested would be the case, most of the places have been easy and  
straight-forward to fix as we stumbled over them one-by-one.

But some cases are not so easy (for me).  For example, in lib/VMCore/ 
Constants.cpp there are several places where (such as isString() )  
that make implicit assumptions about byte size being 8 bits.  I don't  
see a way of getting the target information in play there.  (If you  
know a way, please let me know!! ;-)  I am guessing, however, there  
might be a design change required to get the TargetData info.  Any  
ideas?  Add another argument?  LLVMContext/LLVMContextImpl does not  
seem to provide what I need.

Assuming all of this gets done, there is the important question about  
how it gets tested.  I have a target, but it probably is not of much  
interest to anyone else.  What would people think of having a dummy  
test target just for this purpose until C5000 or something else with  
non-8-bit-bytes becomes available?

Or, is this topic mostly uninteresting to people?   (In that case the  
private fork is looking better and better.)  The problem with this is  
that it cuts through a big swath of the code base (lots of little  
changes) so probably involves most of the code owners.  I think it is  
useful functionality but it might be because I am just being blinded  
by my own narrow set of requirements.

As always, thanks for your help and your time,

Ray



More information about the llvm-dev mailing list