[LLVMdev] Initial thoughts on an LLVM backend for N-address generic assembly

[nkavv at physics.auth.gr]

Hi Justin

> It really depends on your goals and the abstractions provided by the target
> IR.  For NVPTX, we use a traditional LLVM back-end approach (using TableGen
> and the SelectionDAG/MachineInstr/MC infrastructure) because PTX is
> low-level enough to be treated as an assembly language.

I consider NAC (N-Address Code) to be comparably low-level to PTX  
(AFAICS from PTX ver. 3.1 PDF).

> If your IR is more like LLVM IR, then it may make sense to do some kind of
> direct translation from LLVM IR to your IR and bypass the traditional
> codegen approach.

It seems to be that NAC has more resemblance to PTX than LLVM. That,  
there is e.g. a PHI instruction that works in the same way as in LLVM.

I gave thoughts of writing an external translator, but i'm afraid that  
it would be obsoleted if some dramatic change happens to the LLVM  
infrastructure. A backend would be maintainable in the longer term.

> For PTX, we have to walk a fine line compared to other back-ends  
> because PTX is not the machine ISA.

Similarly, NAC is not a specific ISA but a generic, assembly-like,  
input to a high-level synthesis process, mostly involving CDFG  
mapping, operation scheduling, state assignments, resource allocation  
and RTL code generation. The result is a hardware-only  
(non-programmable) architecture that implements the input program.

Regarding machine-independent optimizations, I would basically use  
whatever is supported by LLVM's "opt". Target-dependent optimizations,  
do happen, but as part of the high-level synthesis backend.

> If your IR is meant
> for optimization passes, then it may not make sense to perform all of the
> back-end optimizations available through LLVM, but just use the middle-end
> optimizations performed on LLVM IR directly.

I agree, this is my intention. The IR is meant as an LLVM  
simplification and subset for hardware synthesis.

Best regards
Nikolaos Kavvadias