[llvm-dev] What was the IR made for precisely?

[mats petersson via llvm-dev]

Calling C portable assembler is, in my view, doing both assembler and C a
disservice. Yes, you can, with a lot of knowledge of how a particular
compiler works, and what processor you are on, know what will acutally
happen on a particular machine. But C is not very clearly defined in a lot
of cases. Sizes of types require at least a special header file to be
included to ensure you KNOW if you get a 16, 32, 36, 48 or 64 bit sizes
integer as "int".

LLVM-IR is designed to overcome the trouble of describing some of these
things internally in a compiler. It allows you to write a compiler that has
a well known behaviour, with a little more effort than producing strings in
C (actually, it may be LESS effort, if you get it right and you struggle
with string handling). Also, producing C code for some things will be quite
hard - especially if the C representation isn't straight forward. It's then
just as easy to write LLVM-IR representation (and you can always "cheat"
and write the corresponding code in C, compile it with `clang -emit-llvm -S
myfile.c`, and look at `myfile.ll` to see what was produced, then reproduce
it in your own compiler).

I have written a Pascal compiler using LLVM, and it's really not hard (I'd
say, easier than a Pascal to C compiler, although I have never written one
of those).

One thing to watch out for is that LLVM doesn't "like" big structure/array
arguments being passed from one function to another. You will need to check
the size, and use some trick to copy to temporary, pass a pointer, and use
"byval" to tell the LLVM layer that it's a copy.

--
Mats

On 27 October 2016 at 16:30, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 27 October 2016 at 16:18, David Chisnall via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > LLVM IR is intended as a compiler intermediate representation.  It aims
> to be able to express anything that arbitrary source languages might want
> and anything that target architectures may implement, in a way that is not
> closely tied to either specific source languages or target architectures.
> It doesn’t entirely succeed in this, but it comes a lot closer than C to
> this goal (not surprising, as this was never a goal of C).
>
> Yeah, "LLVM IR is a compiler IR, not a target-independent language".
>
> Lowering your language to LLVM IR is a great way to reduce the cost of
> target-specific knowledge in your front-end 10-fold. But there's still
> the remaining 1/10th that you need to do.
>
> Exception handling is one obviously complicated one, but there's also:
>
> * Procedure-call standard differences: most arguments will marshal
> correctly in LLVM IR, but complex structures sometimes need to be
> lowered to arrays, or moved around.
> * Type sizes: The LLVM lowering is smart enough (in most cases) to
> split too-large values (64-bit int on 32-bit machine), but that's
> error prone and inefficient. You should emit the best types per
> architecture.
> * Your language's ABI: C++ has an ABI which defines the layout of
> classes and objects that can be different between targets. You may
> want to make special concessions due to speed and code-size concerns.
>
> Pretty much everything else should be dealt with by the IR passes and
> lowering.
>
> But the biggest benefit of lowering to LLVM IR is safety.
>
> Lowering to C will actually be lowering to "strings", not proper C.
> Unless you write your own C validation engine (ie. a compiler), you
> can't know if you have lowered to valid C or not.
>
> The IR libraries (IRBuilder et al) give you that for free. This
> immensely simplifies the task of lowering your language, and you can
> focus on what really matters: the semantics of your language.
>
> Hope that helps.
>
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161027/44bc96f4/attachment.html>