[llvm-commits] [RFC] Add x32 psABI support

[Michael Liao]

Hi Chandler

Thanks for your comments and advices.

On Wed, 2012-07-11 at 01:00 -0700, Chandler Carruth wrote:
> On Tue, Jul 10, 2012 at 8:24 PM, Michael Liao <michael.liao at intel.com>
> wrote:


> In the hope that you're interested in being that person (and it seems
> like you are!), what I would suggest is this, in no particular order:
> 1) Put this up on github as a branch of LLVM. You can maintain it in
> the open there so that anyone who wants to experiment or try it can.
> It's possible we could even set up a proper Subversion branch, but
> that seems to have no real benefit over something like github.

Is it possible to set up a branch to maintain x32 psABI support? Setting
up on github would require more process efforts from our side.

At the same time, I will re-split the patches again into even smaller
pieces as some one are generic to x32 psABI support, says not detecting
target by pointer size.

> 
> 
> 2) Start working on the existing x86 backend. There are a lot of hacks
> and kinks in there that could use some serious attention.

Yeah, we are starting to engage into this to improve/refine x86 support.

> 3) Go through the bug tracker, and cherry pick bugs to work on fixing.

We already started that.

> 4) Join the IRC channel, and participate in the community aspects,
> answer user questions, join design discussions, etc.
> 5) Contribute fixes to the target independent parts of the LLVM
> backend. This part could use lots of love and attention, its something
> that any backend will depend on heavily, and can be both very
> educational and very useful.

Definitely, though focusing on x86 backend, any relevant
target-independent work will be addressed as well.

> 6) Maybe try to build this missing piece that would be a very useful
> exercise and benefit the community a
> lot: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050536.html
> 
> 
> 7) Once you've really gotten the swing of the development process and
> have a good rapport with the community, restart the x32 discussion,
> but start it from a different place: Start a *design* discussion about
> how best to support x32 in LLVM and Clang.
> 8) Get feedback from the community about how to design this, what
> refactorings would make it cleaner, easier to support, test, etc.
> Incorporate this feedback, and build consensus and support for the
> work with the community.
> 9) Re-work the code to build on top of the design in #8 and resubmit.
> At this point, the reviews will likely be both much easier, much more
> prompt, and frankly much easier for both you and the reviewers. =]
> 
> 
> I realize this is a *crazy* amount of work "just to add a feature",
> but without something like this, I think it's much harder for the
> project to sustain the quality and speed of development it currently
> enjoys. I also think that at the end of this, LLVM will be better,
> you'll be in a better position to fix and support users of this
> feature, and the feature itself will be better implemented.

That's very helpful comment.

Thanks
- Michael

> 
> 
> 
> 
> 
> 
> Now for some very minor comments to help out assuming you follow my
> rough plan here:
> - Please try to keep things on a single thread. Until the topic
> changes, when you have an update to a set of patches, just attach them
> to a new email in the same thread. That makes it much easier to keep
> track of the discussion.
> - Testing is essential. The current patches have very light to no
> testing. You need to have thorough regression and/or unit tests for
> each patch and each component where you're adding support.
> - Incremental development is king. The smaller and more logically
> focused the patch, the faster it is to code review, and the faster you
> get to iterate. It's a really hard skill to learn, but thinking in
> terms of small steps that build on each other to reach your goal is
> very useful. However, remember that each step should generally be
> testable, and those tests should be added with that small patch so we
> don't regress and don't get untested code into the tree.
> 
> 
> 
> 
> 
> 
> I hope this helps, and sorry for the essay. ;] I'm just long-winded...
> I'm hoping to see more contributions from you!
> -Chandler