[LLVMdev] Newbie question for registering new target with LLVM

[Sandeep Kumar Singh]

Hi Tim,                      Thank you so much for your detailed
guidance e-mail. I am following your points and llvm artifacts. Soon I
need further guidance for next step.
  Regards,                  Sandeep

On 10/12/12, 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.
>


-- 

Thanks and Regards,
Sandeep Kumar Singh