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

[Philipp Klaus Krause]

On 28.08.2012 14:47, Cameron Zwarich wrote:
> On Aug 27, 2012, at 10:39 PM, Philipp Klaus Krause <pkk at spth.de> wrote:
> 
>> On 28.08.2012 14:08, Joshua Cranmer wrote:
>>> On 8/27/2012 9:57 PM, Hongbin Zheng wrote:
>>>> I think the C backend also allow people performing source-to-source
>>>> transform with LLVM (instead of Clang).
>>>
>>> I do not believe that this would be the case nor that it should be a
>>> goal. Source-to-source transformation requires a lot of accurate
>>> information about the AST, and conversion to LLVM IR is way too lossy.
>>> Signedness, for example, is lost at IR generation, as is any pretense of
>>> machine independence.
>>>
>>
>> Why is it not possible to have the C backend emit machine-independent
>> code (i.e. C code that does not rely on implementation-defined behaviour)?
> 
> Because LLVM IR already includes that implementation-defined behaviour.
> 
> Cameron
> 

Sorry, it seems I misunderstood Joshua's mail the first time I did read
it. While the question I asked is one I want to ask, the context may
give a false impression.

Shouldn't work LLVM with the C backend this way:

* The original input is read, and implementation-defined behaviour in
there is assumed to have meaning based on some extra information
supplied (e.g. signedness of char, size of an int, etc)
* LLVM does transformations
* The C backend generates C code, which is machine-independent (i.e.
will behave the same no matter with which C compiler it is compiled with).

The last point is what I meant by "have the C backend emit
machine-independent code (i.e. C code that does not rely on
implementation-defined behaviour)". And I do not see how
implementation-defined behaviour included in LLVM-IR would prevent that.

Philipp