On 17 December 2016 at 23:54, <akshanshcha...@gmail.com> wrote: > For each instruction in any BasicBlock I want to know the type of > instruction, the variables used in that instruction. [...] Just one line > of the program corresponds to multiple instructions. Is there some > documentation as to how these instructions are constructed for a line of > code so that I can decode these instructions for any general program’s SSA. >
The SSA package defines a minimal instruction set sufficient to express the semantics of any Go program. It simplifies the program in certain ways, such as: - replacing many local variable defs and uses by direct graph edges - reducing structured control flow with unstructured jumps - expanding out the effects of "embedding" on field and method selections - simplifying variadic calls with explicit slice operations - defining closures for function literals with free variables. However, it does not "lower" the core data types of Go (slices, channels, etc) to simpler ones, so the sequence of SSA instructions generated for any source construct should be quite intuitive. For examples of how to use the SSA form, take a look at the go/pointer package that lives alongside go/ssa. It processes all the instructions within each function to build and then solve an interprocedural system of constraints: https://github.com/golang/tools/blob/master/go/pointer/gen.go#L934 Alternatively, look at the core function of the interpreter used for testing the SSA construction algorithm. It visits each instruction in turn and simulates its dynamic semantics: https://github.com/golang/tools/blob/master/go/ssa/interp/interp.go#L192 Also, I want to know the variables which are shared bw any goroutines or > not. > To answer this question precisely you need an "escape analysis", such J.D.Choi et al.'s "Escape Analysis for Java" which classifies each variable into one of three kinds: local variables, heap variables local to a single thread, and shared variables. Building an escape analysis is a significant undertaking---similar to and about as complex as the analysis done by the go/pointer package. You can answer this question simply but very conservatively by assuming that all heap variables (Alloc{Heap:true}) are shared by multiple goroutines. > All the instructions where one particular variable is being defined or > used. > Each local ssa.Value (such as an add instruction, BinaryOp{Op: ADD}) has a set of edges (Referrers) to each place it is used. For all other values (e.g. globals) you need to do a pass over the whole program to find all references. I need these infos because my aim is to implement the CSSA based SAT > encoding for a program as mentioned on page 7 of this paper ( > https://goo.gl/pdXuoe). > That paper describes a hybrid static/dynamic analysis, which means it needs to relate facts about a particular concrete execution of a program with facts about a static abstraction of the same program. You will find it easier to implement if you use as much common infrastructure as possible for the two analysis, which means using the gc compiler's SSA representation instead of the one in golang.org/x/tools/go/ssa. I don't wish to discourage you, but if this is your aim, I must warn you that basic usage of the go/ssa package is like walking from the parking lot to the trailhead, and you still have mountains to climb. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
