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

[Dmitry N. Mikushin]

Dear Roel,

Thank you for working on this!
C backend definitely deserves to be resurrected.

Good luck with your effort,
- D.

2012/8/27 Roel Jordans <r.jordans at tue.nl>:
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev