llvm dev - Oct 2012 - [LLVMdev] Newbie question for registering new target with LLVM

Hi all, llvm newbie here.

I'm trying to learn porting with llvm for study purpose. This is my first
query
on llvm mailing list.I have some idea about GCC. I choose 'rx' as a
target to
port as it is also available in GCC. I have done some initial changes with llvm
source code to register target with llvm. I need to verify these changes. Can
anyone please take a chance to verify it.

Build Command(s):
================configure --enable-targets=Rx,arm
--prefix=/home/sandeep/LLVM/prefix/
--enable-languages=c,c++
make
make install

File(s) that I have modified to register new target with LLVM infrastructure:
============================================================================1)
llvm/configure

  1.1) Rx-*)        llvm_cv_target_arch="RX" ;;
  1.2) Rx)          TARGET_HAS_JIT=0
  1.3) case "$enableval" in
       all) TARGETS_TO_BUILD="X86 Sparc PowerPC Alpha ARM Mips CellSPU
XCore
            MSP430 SystemZ Blackfin CBackend CppBackend MBlaze PTX Rx" ;;
  1.4) Rx)  TARGETS_TO_BUILD="Rx $TARGETS_TO_BUILD" ;;
  1.5) Rx)  TARGETS_TO_BUILD="Rx $TARGETS_TO_BUILD" ;;

2) lib/Support/Triple.cpp
  2.1) case Rx:      return "Rx";
  2.2) if (Name == "Rx")    return Rx;

3) lib/Target/Rx/RxTargetMachine.h
namespace llvm {
  class RxTargetMachine : public LLVMTargetMachine {
  public:
        RxTargetMachine(const Target &T, StringRef TT,
                        StringRef CPU, StringRef FS,
                        Reloc::Model RM, CodeModel::Model CM) ;
};
        extern Target TheRxTarget;
}

4) lib/Target/Rx/TargetInfo/RxTargetInfo.cpp
using namespace llvm;
Target llvm::TheRxTarget ;
extern "C" void LLVMInitializeRxTargetInfo() {
  RegisterTarget<Triple::Rx> X(TheRxTarget, "rx",
"Rx");
}
extern "C" void LLVMInitializeRxTargetMC() {}

5) lib/Target/Rx/TargetInfo/Makefile
LEVEL = ../../../..
LIBRARYNAME = LLVMRxInfo

# Hack: we need to include 'main' target directory to grab private
headers
CPPFLAGS = -I$(PROJ_OBJ_DIR)/.. -I$(PROJ_SRC_DIR)/..
include $(LEVEL)/Makefile.common

6) lib/Target/Rx/TargetInfo/CMakeLists.txt
include_directories( ${CMAKE_CURRENT_BINARY_DIR}/.. $ \
{CMAKE_CURRENT_SOURCE_DIR}/.. )

add_llvm_library(LLVMRxInfo
  RxTargetInfo.cpp
  )

add_llvm_library_dependencies(LLVMRxInfo
  LLVMSupport
  LLVMTarget
  )

7) lib/Target/Rx/RxTargetMachine.cpp
using namespace llvm;
extern "C" void LLVMInitializeRxTarget() {
  RegisterTargetMachine<RxTargetMachine> X(TheRxTarget);
}
RxTargetMachine::RxTargetMachine(const Target &T, StringRef TT,
                                 StringRef CPU, StringRef FS,
                                 Reloc::Model RM, CodeModel::Model CM)
                                 : LLVMTargetMachine(T, TT, CPU, FS, RM, CM)
{ }

8) lib/Target/Rx/Rx.td
include "llvm/Target/Target.td"
def RxInstrInfo : InstrInfo;
def Rx : Target {
  let InstructionSet = RxInstrInfo;
}

9) lib/Target/Rx/RxAsmPrinter.cpp
using namespace llvm;
extern "C" void LLVMInitializeRxAsmPrinter() {
    RegisterAsmPrinter<RxAsmPrinter> X(TheRxTarget);
}

RxAsmPrinter::RxAsmPrinter(TargetMachine &TM, MCStreamer &Streamer)
                           : AsmPrinter(TM, Streamer){}

10) lib/Target/Rx/Makefile
LEVEL = ../../..
LIBRARYNAME = LLVMRx
TARGET = Rx
DIRS = TargetInfo
include $(LEVEL)/Makefile.common

11) lib/Target/Rx/CMakeLists.txt
set(LLVM_TARGET_DEFINITIONS Rx.td)
add_llvm_target(Rx
  RxTargetMachine.cpp
  RxAsmPrinter.cpp
  )

add_subdirectory(TargetInfo)

12) lib/Target/Rx/RxAsmPrinter.h
namespace llvm {
class RxAsmPrinter : public AsmPrinter {
public:
    explicit RxAsmPrinter(TargetMachine &TM, MCStreamer &Streamer);
};
    extern Target TheRxTarget;
}

13) include/llvm/ADT/Triple.h
    Rx,

14)          autoconf/configure.ac
    Rx)          AC_SUBST(TARGET_HAS_JIT,0) ;;
    rx)          TARGETS_TO_BUILD="Rx $TARGETS_TO_BUILD" ;;
    Rx)          TARGETS_TO_BUILD="Rx $TARGETS_TO_BUILD" ;;
    Rx)          AC_SUBST(TARGET_HAS_JIT,0) ;;

After done above changes, dummy compiler is built successfully. I have tested:

Registered target is tested with below tool:
============================================[sandeep at D-5745 LLVM]$
prefix/bin/llc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 3.0
  Optimized build.
  Built Jul  2 2012 (15:19:13).
  Host: i386-pc-linux-gnu
  Host CPU: penryn

  Registered Targets:
    Rx    - rx  <===  New registered target
    arm   - ARM
    thumb - Thumb

Doubts/question(s)
=================1) To build dummy compiler:

 1.1) Please verify all above change(s) are OK? or I have modify some code?
 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.
 1.3) Please help me from anyone of llvm lovers :-) to proceed further. What
      modifications required to generate rx assembly of hello word program.
	
Any help will be highly appreciated.

Sandeep Kumar Singh

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.

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

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