Hi Mobi,
Thanks for your response. :-)
> *Veterans could tell you more, what I say may be wrong, it is just based
on my still enough poor understanding of clang and LLVM nonetheless poor
understanding of the paper.*
In the first stage of my post, I just show the general picture how I try
to get the dynamic data dependence. The paper only focuses on how to
analyze the ready trace and produce dependence results. Actually, it does
not related with the problem I post, just for describing the whole picture.
If you do not know the paper, it is totally fine and will not affect the
discussion on the problem. The problem comes before the analysis step
(before we can use the method in the paper), "how can we ignore the
uninteresting load/store instructions".
> *What I mean with AST is that you can static-analyze your AST to find the
"to dynamically analyze" points and inject code (also in form of AST)
in
form of "report now that there is a read from array (memory)" or
"now there
is a save to memory". This would give though tons of false positives as the
compiler will optimize out lot of stuff, so I think it would be a false
positives. To understand this in details you should read how the clang
compiler works.*
I check clang AST, it seems to only provide source-level information.
What I mean to inject code, is to insert a Call Instruction right before or
after an interesting load/store instruction. Therefore, it seems it could
not provide me enough information. I think one solution might be using
debugging information and make a connection between llvm instructions with
source code lines, then specify the uninteresting source code lines. I
guess this approach will work, but I am still finding better solutions.
> *tools/libraries like vallgrind, dynamorio, intel.pin are in my opinion
more specialized for what you probably want to do. Anyway I think mainly
there are two approaches. You either inject analysis code near the
instructions to be observed or you run your code through an interpreter
(vallgrind or llvm) and try to "catch" what you are interested in.
With
"AST" hacking you could inject code I think more precisely than any of
the
other tools... but all depends on what exactly you want to measure. *
Yes, you're right, it depends on what I want to get. Actually, the
instrumentation part is not a problem now and I have integrated an embedded
Execution Engine inside my project, I just try to finish the last part of
my project. The reason why I do not consider the other tools, like Pin or
something is that my later research project is strongly related with LLVM
and I need the trace and llvm-IR for further usage. :-)
Thanks,
Henry
On Thu, Dec 11, 2014 at 11:55 PM, mobi phil <mobi at mobiphil.com>
wrote:>
> Veterans could tell you more, what I say may be wrong, it is just based on
> my still enough poor understanding of clang and LLVM nonetheless poor
> understanding of the paper.
>
> What I mean with AST is that you can static-analyze your AST to find the
> "to dynamically analyze" points and inject code (also in form of
AST) in
> form of "report now that there is a read from array (memory)" or
"now there
> is a save to memory". This would give though tons of false positives
as the
> compiler will optimize out lot of stuff, so I think it would be a false
> positives. To understand this in details you should read how the clang
> compiler works.
>
> But I think nobody could give you a precise answer without reading the
> paper in question you marked with [1] especially that you did not provide a
> link to it.
>
> tools/libraries like vallgrind, dynamorio, intel.pin are in my opinion
> more specialized for what you probably want to do. Anyway I think mainly
> there are two approaches. You either inject analysis code near the
> instructions to be observed or you run your code through an interpreter
> (vallgrind or llvm) and try to "catch" what you are interested
in. With
> "AST" hacking you could inject code I think more precisely than
any of the
> other tools... but all depends on what exactly you want to measure.
>
> Think also about performance. Running such an analyzis through an
> interpreter often is impossible (valgrind, llvm). Myself I had to do some
> profiling with valgrind, but given that starting the server in real
> situation took half an hour. Running it through valgrind (thus intepreter)
> took one day (if it was not crashing) ;) which made it impossible to use at
> the end...
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141212/53470486/attachment.html>