[LLVMdev] [cfe-dev] thoughts about n-bit bytes for clang/llvm
Arnaud Allard de Grandmaison
Arnaud.AllardDeGrandMaison at dibcom.com
Thu Sep 24 01:16:09 PDT 2009
Hi Ray,
At DiBcom, our application specific processor is using 16-bits byte, and it would definitely be of interest for us to have the support for n-bit bytes.
By using alignment restrictions, and adjusting the adresses' computations in a few target specific places, we have been able to have it work in our own specific case. But this is not clean, and most probably not portable to most other targets.
Best regards,
--
Arnaud de Grandmaison
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ray Fix
Sent: Thursday, September 24, 2009 1:16 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [cfe-dev] thoughts about n-bit bytes for clang/llvm
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
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list