You can achieve the 'standalone tools' effect using LLVM bitcode,
which is a binary IR format.
Then you can have:
source code -> [llvm-gcc frontend] -> bc
bc -> [your tool using llvm bitcode reader writer library, doing
whatever mutations to the IR you want and spitting out bc again] -> bc
bc -> [llvm backend (llc)/llvm-as/...] -> native code.
Doesn't that meet your requirements?
On Wed, Mar 25, 2009 at 8:09 PM, jstanier <j.stanier at sussex.ac.uk>
wrote:>
> Thank you both for your answers.
>
> The only reason I was interested in not using the built-in parsing library
> was that it would give me more flexibility over the language I program in,
> but if it means brushing up on my C++ then this isn't too much of a
problem
> either.
>
> With regards to using the in-memory LLVM, that's also a good approach.
> However, I was thinking of structuring my thesis work as standalone tools
> (much like llvm-as and the others) as it would help me structure my work
> better. I hope this makes sense.
>
> Best,
>
> James
> --
> View this message in context:
http://www.nabble.com/Rolling-my-own-LLVM-assembly-language-parser-tp22704803p22707497.html
> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>