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
>