[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