[llvm-commits] [PATCH llvm, clang llvm-gcc] Add TCE targt to LLVM and CLANG support for generating bytecode to TCE architecture.
Mikael Lepistö
lepisto.mikael at gmail.com
Mon Aug 17 03:18:39 PDT 2009
On 17.8.2009, at 12:09, Eli Friedman wrote:
> 2009/8/17 Mikael Lepistö <mikael.lepisto at tut.fi>:
>> The value of having tce target in llvm is to be able to use clang for
>> generating bitcode with correct integer and floating point sizes and
>> alignments for tce target. So in the best case we can get rid of
>> llvm-gcc
>> cross compiler, which we are currently using for generating the
>> bitcode.
>
> As this applies to TCE-target-rc3.patch: We generally don't add
> backend targets until they are at least somewhat usable. We don't
> want to clutter the tree with unusable and unmaintained targets, and
> having a somewhat complete target is a sign that you're planning to
> continue maintaining the target. In particular, adding this before
> 2.6 branches entails additional work writing the release notes, etc.
> for a target which is unusable.
>
Actually we would liked to add the target to llvm because, otherwise
we cannot set correct target triplet and data layout information to
bitcode which is generated with llvm-gcc cross-compiler (currently
cross-compiler puts just mips data layout and triple even if code is
compiled differently). I thought that clang target also would have
required tce target to exists in llvm, but looks like I was wrong and
that the clang tce target works without it just fine without
additions to llvm.
Our real target machine in our (publicly available) repository,
because parts of the target machine must be compiled as plugin, to
meet TCE target processor configuration's register files and
instruction set. It is not ready to be imported to llvm because it
uses our own libraries for builiding target binary and would cause tce
dependency to llvm. It has been maintained since llvm 2.2.
> As this applies to TCE-clang-target-rc3.patch: It's not directly
> affected by the other patch, but it's hard to justify adding the
> target to clang when it's not usable by anyone else.
I'm not sure how it would be even possible to make it more usable for
anyone else, since the TCE TTA application specific processor is
developed by us and all the design tools as well.
Design tools are publicly available (MIT licence) and takes program
input in llvm bitcode format. So everyone who is developing TCE
application specific processors and software for them can use the
clang target.
> In any case, the
> proper place to submit clang patches is cfe-commits.
I'll send clang patches there in future :)
Basically we can live without llvm patching and continue using llvm-
gcc target as we have used before (it's pretending to be mips target)
and it's not strictly necessary to try to link clang and llvm-gcc
generated code together. But for starting to use clang as our C
compiler, we would need the clang patch to be applied.
The reason why we would like to start using clang is the address space
attribute. Also in future we would like to add or see restricted
pointer support.
Mikael Lepistö
More information about the llvm-commits
mailing list