[LLVMdev] [RFC] Resurrecting the C back-end

[Roel Jordans]

Hello all,

I am in need for a working C back-end for LLVM for my current research. 
I know that the previous incarnation of this back-end has been kicked 
out of the tree since the 3.1 release and I have gone through the 
archives to restore it to it's previous 'glory'.

So far, I have restored most of the previous version (excluding some of 
the parts that needed changes outside of the lib/Targets/CBackend 
directory) and I have made the necessary changes to get it back in 
'working' state.

I have already had some short discussion on the IRC channel (with 
baldric IIRC) and he suggested to include type legalization in the list 
of passes to run before generating the output in order to get support 
for arbitrarily sized types.

Some other things I am considering for inclusion as improvements to the 
new CBackend include the following:

* Simplification of the output
   o Printing only the required set of headers/defines for a specific module
   o Reducing the number of explicit type casts in the generated code
   o Optionally removing the current prefix 'llvm_cbe_' to named variables
   o Only printing full prototypes of structs when their internal fields 
are actually referred to within the module. (e.g. when using library 
calls like fopen a complete description of the struct FILE is generated 
whereas a simple 'struct FILE;' should be sufficient.

* An option to insert software floating-point calls and/or library calls 
for things like division (I have an embedded processor as target system 
in my research which can not always support costly operations)


My hope is that, in generating a more simplified output, it is possible 
to produce a more friendly yet portable output.

Furthermore, some of the current features are outside of the scope of my 
current work and could make it more difficult for me to maintain the code.

For example, the previous back-end seems to put quite some emphasis on 
the different linkage types and the properties of various C compilers 
that are required in order to correctly represent them. My guess is that 
this is irrelevant for most of the use-cases of the C back-end while it 
could take me quite some time to support.

A similar example is the handling of inline assembler statements, which 
required a per-target support for e.g. the translation of register 
names. For now, this is not something I need (my target architecture is 
not supported by LLVM anyway) and I consider myself not yet familiar 
enough with the LLVM internals to offer support for this feature.


Anyway, that brings to my final question: Which features are 
critical/important/wanted/unwanted for a C back-end?

Cheers,
  Roel