[LLVMdev] seeking advice
arnobastenhof at gmail.com
Tue Aug 4 02:43:30 PDT 2015
Many thanks for the detailed replies and advice. If I may attempt to
summarize, my plans as I described them were rather heavy on the theory,
and the foremost piece of advice, I think, is that theory typically settles
itself into memory much better if it can be readily attached to prior
experiences. Hence, it is better introduced more gradually in favour of
first gaining familiarity with the IR by writing a front-end for it, using
the ample documentation already available. This will provide knowledge of
something very concrete (the IR) that will help grasp the implications of
the more advanced concepts more easily once I start learning about them, as
well as provide a basis to start digging more deeply (say, writing
optimizations or even a back-end).
As for a concrete project, while most is still new to me, I did already
dabble a little with Prolog implementations recently, having written a
parser and bytecode interpreter for a small fragment using a stack-based
machine (then still in Java, though I would now like to practice with C).
There's several papers showing how abstract machines for Prolog can be used
as intermediate languages for actual compilation down to machine code
(e.g., GNU Prolog: Beyond compiling Prolog to C), and targeting the LLVM IR
instead should then not be too hard once the latter is well understood.
Again, many thanks for the inspiring advice and success stories. Also,
Mukul, I'm very happy to receive any sort of advice and would never feel
offended by it. (So, to repeat myself once more, many thanks!)
On Mon, Aug 3, 2015 at 9:24 PM, Mukul Sabharwal <mjsabby at gmail.com> wrote:
> Good recommendations on the thread already, but let me add by saying
> you don't _need_ to learn C or C++ to use LLVM; of course
> contributions would require familiarity with C++. You can use a
> library that talks to LLVM in your favorite language, and if that's
> Java, this seems to be the most up-to-date project with bindings:
> Let me also critique your reading list if your goal is writing a first
> compiler. Understanding SSA, optimizations, etc. is 10x more lucid
> (and you appreciate it more) when you see some IR or assembly and the
> impact a certain optimization or concept can have on it. Let me be
> clear, your reading list is bang on for some topics, but I feel like
> you'll miss some "aha" moments if you've not actually written some
> code first-hand, or maybe gone through some simple code generation
> steps (even if it's reading code).
> In college, I took a course (and did well) on compiler optimizations
> (program analysis to be specific) and we went through pretty much all
> what is needed (theory) to build an optimizing compiler: cfg
> construction, dataflow frameworks, SSA form, fixed points, lattices
> and abstract interpretation, etc. but a few years hence without using
> any of that it's been somewhat of a re-learning this past year or so.
> The formal education there was absolutely critical for the concepts,
> but I didn't get something tangible at the end of it.
> If optimizations are really what you want to understand or implement,
> might I suggest starting with the one of the simplest ones: Constant
> folding. It's simple to implement yet there is a feeling of
> Finally, to be honest since learning is an individual experience my
> suggestions may not at all be helpful, but if you learn like I do ...
> by doing, they just might.
> P.S. - I have no idea about your level of cs understanding is, so
> please don't be offended if what I've suggested is too naive or simple
> for you.
> On Mon, Aug 3, 2015 at 10:07 AM, Renato Golin <renato.golin at linaro.org>
> > On 3 August 2015 at 16:29, Arno Bastenhof <arnobastenhof at gmail.com>
> >> Based on these
> >> readings, as a matter of exercise I can take what I learnt from LCC to
> >> a small compiler in C targeting the LLVM IR for, say, a subset of
> > Hi Arno,
> > This is not a monumental task. There are many tutorials in the LLVM
> > tree, and producing IR from a simple AST is actually simple and
> > straight-forward.
> > So many languages can target LLVM IR, that it's very hard that you'll
> > find something that cannot be represented in IR. At least something
> > that other implementations haven't found already, and worked around.
> > With your broad knowledge in CS, I wouldn't expect you to take more
> > than a month or two to get a front-end working with the JIT compiler
> > on a reasonable subset of Prolog. Of course, the deeper you go, the
> > more time it takes to progress the same 1%, but you can always stop
> > when productivity drops as fast as enjoyment. :)
> > But you won't need to understand the back-end at all, modulo some
> > quirks on your platform of choice. The hint is to write the same logic
> > in Prolog and C, compile the C with Clang and see what they do. If you
> > spot hackery, the least resistance path is to replicate the hackery.
> > Asking on the list is also a good way to understand why the hackery,
> > and maybe even give you an entry point into changing the middle/back
> > end to support a proper construct in IR for better codegen.
> > From there, I'd recommend you to try different targets. Get some
> > board, device, phone you have at your disposal (RaspberryPi2 is a
> > great inexpensive kit), and make it work. You'll take a lot less
> > effort than you're imagining...
> > cheers,
> > --renato
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev