[LLVMdev] CBE progress and design

[Roel Jordans]

On 10/10/12 18:57, Nadav Rotem wrote:
> Hi Roel!
>
>
> On Oct 10, 2012, at 5:29 AM, Roel Jordans <r.jordans at tue.nl> wrote:
>
>> Hello all,
>>
>> As some of you may remember, I am trying to get the C back-end back in working condition.  I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the current trunk.
>>
>
> Do you have a public git repo ?
>

Not yet, though I have my own local git to keep track of my changes. 
Should I just make that repository public or is there some 'usual way' 
of making a public git?  Secondly, is there an easy way for my git to 
keep track with the LLVM trunk or should I try to update when I have 
made the majority of my changes?

>>
>> === Question 1: new design feedback ===
>> I am currently looking into moving the CBE to run after the initial lowering and type legalization phases so that it can support arbitrarily sized data.
>
> I like this approach.
>
>>   However, both lowering and type legalization require target information about the supported types and operations.  Or more specifically, they need a TargetLowering to be defined.  My current problem is that I have no clue on what should be in there as this will probably be very dependent on the intended use of the CBE.
>>
>
> I think that the target should reflect the C language. You can turn i64 to int64_t, etc.  I think that you can avoid all of the target-specific details of C, like sizeof.  In that case, you can define an arbitrary target. The new target will support all of the types that C supports (such as i32 for uint_32, i8 for char, etc).
>

I have been thinking about this but one of the main target compilers I 
would like to support doesn't have support for int64_t so the 
availability of such features should be optional for me in a new 
'generic C' target, that's why I was proposing the alternative of using 
existing targets and allowing myself to use those as a way of configuration.

> Also, are you trying to reconstruct the control flow ?  That would be a nice feature.

Control-flow reconstruction is not on my priority list, control-flow is 
currently just handled with ifs and gotos.  It may be on my todo list 
once I get the basic functionality working as I am pretty sure that my 
target compiler will not be able to do software pipelining on 
non-structured loops.

>
>> I currently have two options for solving this.  My question to you is what you think of them and do you have other suggestions for me to look into?
>>
>> 1) I could try to make a generic, configurable, CTargetLowering and allow the user to specify all kinds of things.  However, I am not yet familiar enough with LLVM's CodeGen framework to trust myself to get this complete enough without spending a huge amount of time in figuring out what should and should not be relevant for the CBE.
>>
>> 2) Another option I thought of was to try and use an existing TargetLowering from the other back-ends.  To achieve this I would get the original target from the IR module and try to dynamically load the corresponding target description, including the lowering and type information.  That way I could at least get some information without having to think of the specifics for now.
>>
>> One way to add manual configuration is to make a 'generic' back-end which provides user configurable versions of the required information. I should also know what kind of information is required by the time I have a working CBE using existing target information.
>>
>>
>> === Question 2: getting things into LLVM ===
>> Some people have already asked me to send them my patch for the current CBE.  It is my goal to get the CBE back into the main LLVM repository in the end.  However, my changes during the move of the CBE to after legalization will probably make the new CBE drastically different from the current version.  My guess is that I should first try to get the new version working (somewhat) before we start working on getting it into the trunk.
>>
>> My question here is at what point should I start trying to get things into the LLVM SVN and how can I organize my work to make the inclusion as painless as possible?
>>
>>
>> Best regards,
>> Roel
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>