CBE progress and design

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.

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

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)

Hi Roel!

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 think people just roll their own git clones and generate patches when it is time to commit upstream. There is an "unofficial" mirror on github[1], you could use that start a fork there. I wouldn't worry too much about the "unofficial" tag in the name, as long as the commit ID matches.

[1] https://github.com/llvm-mirror/llvm

General git advice: For keeping track, "git rebase" or "git pull --rebase" is your friend. Or nightmare. It depends. Generally, its good practice to rebase as often as possible, so that your effort remains incremental. But life becomes very interesting when some drastic change like a rename lands upstream, and every commit in your branch needs manual resolution during the rebase. At times like that, I have found it useful to clump my small incremental changes into larger changes on a new branch and then rebase that new branch instead. That's also a good time to abandon ye olde text editor (temporarily) and grab a GUI tool like p4merge or something.

Sameer.