On Wed, 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.
>
>
> === 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.
> 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 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.
Just as an aside: if you're going to this I suspect it'd be best to do
it in a git repo where you can commit incrementally (including a
commit that properly undoes the commit that deleted CBE so we have a
better chance at walking the history (I realize it'll still look like
you committed the whole CBE in one go, but at least it'll match up
with the contents of the deletion commit so it can be walked with that
extra manual step)). This may also make it easier to review your
changes separately from the entire existing backend code.
(other than that, I have no actual investment in/opinion/authority on
this issue)
>
> 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