llvm dev - Jun 2014 - [LLVMdev] A question about running Clang after LLVM passes

On 6/12/14, 9:29 PM, Padefic wrote:
> I am doing a research project. I want to run the DSA pass of LLVM, and 
> use its result in Clang for automatic fixing. I have to use Clang 
> because the line numbers in Clang are accurate so that I can change 
> code accordingly, while LLVM IR seems to lose the information.
If I understand what you're saying, you're building a refactoring tool 
that does some analysis on the program and then changes the original 
program's source code.  Is this correct?

I do not think that this is a good idea.  DSA operates on the LLVM IR.  
Not only will you have the headache of making DSA's results available to 
Clang, but Clang "sees" the program at the Clang AST level while DSA 
"sees" the program at the LLVM IR level.  Mapping DSA's results
from the
LLVM IR back to the AST that Clang creates will be painful in the best 
case and will probably not work reliably at all in the worst case.

I think your best option is to build a points-to analysis that works at 
the Clang AST level and put it into clang directly.  There might be the 
issue of how to build an inter-procedural points-to analysis with Clang, 
but I think there either is a way for Clang to do that, or there is work 
to make Clang do that.
>
> I need to access the objects created in LLVM pass  to get information. 
> Thank Bruce for your advice, could you explain more about how to 
> output using the C backend? Does it mean to output to files, which 
> then input into Clang? I would appreciate any reference on this problem.
The C Backend generates C code instead of native assembly code.  The C 
code it generates is ugly and looks almost nothing like the original C 
source code that was compiled.  Again, if you're building a refactoring 
tool, this is probably not what you want.

Regards,

John Criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140613/a45dff4a/attachment.html>

> The C Backend generates C code instead of native assembly code.  The C code
> it generates is ugly and looks almost nothing like the original C source
> code that was compiled.  Again, if you're building a refactoring tool,
this
> is probably not what you want.
It's also been extinct for a couple of years, hasn't it?

Cheers.

Tim.

On 6/13/14, 9:22 AM, Tim Northover wrote:
>> The C Backend generates C code instead of native assembly code.  The C
code
>> it generates is ugly and looks almost nothing like the original C
source
>> code that was compiled.  Again, if you're building a refactoring
tool, this
>> is probably not what you want.
> It's also been extinct for a couple of years, hasn't it?
I think someone might be in the process of bringing it back to life (or 
might have already done so).

In any event, even if it does exist in modern LLVM, I don't think it's 
the solution for Padefic's issue.

Regards,

John Criswell
>
> Cheers.
>
> Tim.