[LLVMdev] Newbie question for registering new target with LLVM

[Sean Silva]

Hi Tim,

Have you considered taking your knowledge about writing backends and
improve the current documentation? I have made a document which should
allow you to get up and running writing documentation extremely
quickly and easily; you can find it at
<http://llvm.org/docs/SphinxQuickstartTemplate.html>.

Any help is greatly appreciated. Even just a slightly more expository
coverage of the material in your email would be a great addition to
the docs, and could serve as a seed for others to improve. This email
reply you just gave seems like it would fit really well into a new
document "How To dive into developing an LLVM backend"; you appear to
have a good recollection of how you "dove in" :)

Thanks,

-- Sean Silva

On Fri, Oct 12, 2012 at 7:28 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> Hi,
>
>>  1.1) Please verify all above change(s) are OK? or I have modify some code?
>
> Parts will almost certainly have to change in future, but if it builds
> that's an excellent first step.
>
>>  1.2) In LLVM, can we proceed our development like as GCC i.e. incremental
>>       approach? In case of yes, please provide me any reference.
>
> Incremental is definitely possible. I started out with the most
> trivial of functions:
>
> define void @foo() {
>     ret void
> }
>
> and worked on from there in roughly this order:
>
> + Global variables (gives you guaranteed non-dead values to test
> everything with and is likely simpler than getting procedure call ABIs
> correct).
> + Simple arithmetic to make sure I'm not being completely insane in my
> design decisions and get an idea of how the XXXInstrInfo.td will work
> + Stack spills and function prologue/epilogue.
> + Function calls and arguments.
>
> After about the second stage I was implementing wide swathes of the
> processor's instruction space, to give me the instructions needed to
> support the more complicated details.
>
>>  1.3) Please help me from anyone of llvm lovers :-) to proceed further. What
>>       modifications required to generate rx assembly of hello word program.
>
> As far as a backends go "Hello World" is not a small goal, though it
> could be reached reasonably quickly if you're willing to put in hacks
> that'll have to change later.
>
> It's probably best to start trying to compile simple functions and
> keep adding bits until that works. Anything you're not sure of but
> that needs to be present for compilation, put an
> llvm_unreachable("What's going on here?") so that you get to see
> what's actually happening when it reaches that code and don't have to
> guess what's needed.
>
> Even compiling the simplest "define void @foo() { ret void }" is
> likely to require quite a bit more infrastructure. Most of the files
> in the existing backends are needed (possibly in a much simplified
> form) for that function. I think the most important things you'll need
> start in just two places and gradually depend on all the real
> features:
>   + RxTargetMachine.cpp is small, but central. It's where you register
> the passes that actually do the work. If you can get things to compile
> with these functions doing their job you should have stubs for most of
> the necessary components.
>    + InstPrinter/XXXInstPrinter.cpp: This is the main entry for the
> so-called MC instruction printing, which is the good way to do things.
> It's theoretically possible to get your instructions printing without
> creating this, but you'd be Doing It Wrong.
>
> But most importantly, have fun and don't be afraid to ask more
> detailed questions on the lists when you hit problems!
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev