gvenn.cfe.dev at gmail.com
Wed Jan 13 14:28:42 PST 2010
On Jan 13, 2010, at 12:46, Dustin Laurence wrote:
> On 01/13/2010 04:08 AM, Garrison Venn wrote:
>> If it helps, to see what is involved, outside of a pure IR context,
>> see the example code, and doc at:
> It does, although in the "let me show you why this is too much to
> tackle" way.
Yeah, I hear you. The LLVM developer fly trap got me. ;-)
>> Although this is a pure example that shows several test cases,
>> including foreign exception interaction, it is not an IR example, but
>> rather a LLVM IR API example. It would be interesting to see a pure
>> IR version of a personality function. I don't see why this would not
>> be possible, although costly in terms of effort. Clang would help.
>> There are also ways to lower your invoke/unwind into a
>> setjump/longjump implementation, but I do not know how to do this in
>> IR, as it requires function pass setup which is outside the scope of
> I don't know enough about how setjmp/longjmp are implemented to have a
> clue. If I'm getting into uncharted territory it's easier to just
> unwind the evaluator stack by hand, just as I already did with the
> parser when unwinding didn't work. The focus is on learning IR and
> about the simple lisp evaluation model.
For pedagogical purposes, the lowering is accomplished by an IR to IR graph transformation
that you add to a function pass manager. I personally view LLVM as a term re-writing
system where the rules are controlled by the developer a priori. The above IR to IR
transformation is one of these rules, which in LLVM parlance, and from a compiler viewpoint,
is a pass. See -lowerinvoke in http://llvm.org/docs/Passes.html for the command line option. See
llvm::createLowerInvokePass(...) in Scalar.h; note the comments. However this kind of
implementation does not do stack unwinding but rather creates the standard longjmp to a pevious
setjmp behavior. This is why I thought the pursuit of the zero cost (exception setup with no throw), unwind
approach was worth being caught by the venus fly trap.
> There are actually limits to my madness, you know. :-) It would be more
> profitable to learn another aspect of the system by implementing a MMIX
> back-end or something.
Funny I was thinking the same thing. Implementing MIX would be a cool way to learn the other side
of LLVM (backends). I didn't even know there was a MMIX until your email forced me to query.
> Or, and I know this is just *crazy* talk, I could actually follow the
> intended learning path and use the main C++ API for something. :-)
Well, even though I did not take your route, I still use the IR ref. doc as my true documentation. It is
fairly isomorphic to C++ IR API. So I think your approach is worth while.
More information about the llvm-dev