Thanks cedric,
I will look into the ways the debug information could be used.
However, it seems like i would have to write a piece of code that would
successively reduce the conditional predicate in terms of the local and
global variables (of the code). I plan to do it like this.
Since i am using a runonBasicblock pass, the context information between two
basic blocks cannot be shared, since the pass runs on each basic block at a
time. So the idea is to print the output of the pass into a database (a text
file). This database is then parsed to populate a prefix tree, where the
nodes are the temporary variables and llvm opcodes. This tree would be
consumed to eliminate the temporary variables and replace the opcodes by an
expression in a c like format (infix arithmetic notation ).
Since in the begining of each basic block the local/global variables are
loaded into temporary variables, it is understood that the expression would
be in terms of these local/global variables since the temporary variables
would have been already consumed by the aforementioned process.
How does it sound like? Is it possible for the llvm-gcc to emit the bitcode
in a form which is close to the source language (atleast the variable
names). Are there some optimizations possible ?
Thanks alot
Regards
Prabhat
On Dec 19, 2007 7:32 PM, Cédric Venet <cedric.venet at laposte.net> wrote:
> > The questions are:
> > 1. Is it possible to somehow intersperse IR and highlevel code of the
> program (in C or C++).
>
> > Suggestions and answers are welcome.
>
> You can probably use debug information (generated by llvm gcc on intrinsic
> form, see MachineModuleInfo.h) to identify the source ligne for a
> condition
> and the relation between the temporary llvm variable and the high level
> language variable.
>
> Perharps it isn't very reliable but I don't see other solution with
llvm.
> (But I am just a novice).
>
> If you are just doing flow graph analysis, you can consider doing it at
> the
> C/C++ level. Clang (which only support most of C at the moment) as a
> little
> framework for this kind of analysis and it will probably be expended.
>
> Just my 2cents
>
> Regards,
>
> --
> Cédric
>
>
> _______________________________________________
> 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...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071220/9ab703bc/attachment.html>
