[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