I don't think the "#if defined(VENDOR_OSP)" is needed for these kinds of
changes. Could you please remove them?

2011/7/26 Wu Yongchong <wuyongch...@gmail.com>

> Hi, all
> Can a gatekeeper help review this patch
>
> This patch adds support to print VCG graphs for procedure CFGs, at
> various points in CG.
>
> Specifically, the 'V' character can be used (to create VCG graphs)
> wherever the 'r' character is used to print the CG IR.
> Examples:
> -Wb,-tVa - create a VCG graph, in CG, for all phases where we would
>           dump the IR
> -Wb,-tVSCH create a VCG graph just for the scheduling phase.
> Currently, these options only support VCG generation in CG; however,
> they could be extended to support VCG generation in phases that come
> before CG.
> VCG graphs are named as follows:
> <procedure_name>.<phase_name>.vcg
> So for a procedure 'proc', -Wb,-tVSCH will create a file called:
> proc.SCH.vcg.  This way, the -Wb,-tVa option can create multiple VCG
> files - all with unique names.  "phase_names" are obtained from the
> "Phases" table in tracing.c
>
> Some notes on implementation:
> The implementation uses the existing functionality to print BBs, OPs,
> ... The difference is that for VCG graphs, we need the BBs, OPs, to be
> printed to a string rather than to a file.  The lowest-level helper
> functions (e.g. Print_OP_No_SrcLine) call fprintf a large number of
> times.  Rather, than overhauling this code, to print to either a
> string or a file, a simpler approach was taken:
> - print BBs to a temporary file
> - Read the file into a string.
> This made the implementation much simpler, *and* it was much less
> intrusive to existing code.  In addition, modifying the existing code
> would have involved either:
> - testing on multiple platforms (which were not available to the developer)
> - only providing support for certain platforms (which would make the
> existing code even more complex).
> Printing to a file and reading back to a string obviously takes more
> time than writing directly to a string; however, given that this is an
> internal option only, a slight increase in compile time should be
> acceptable.
> -------------------------
> Following is an example to use VCG
>
> $ cat vcg.c
> extern void foo(int x);
> extern void bar(int x);
> extern int x;
>
> void
> sub (int z)
> {
>  if (z == 42) {
>    foo(x);
>  }
>  else {
>    bar(x);
>  }
> }
>
> $ opencc -O -c -Wb,-tVa vcg.c
> $ ls *.vcg
> sub.EBO.vcg  sub.EXP.vcg  sub.GCM.vcg  sub.LOP.vcg  sub.SCH.vcg
> sub.EMT.vcg  sub.FLW.vcg  sub.GLR.vcg  sub.LRA.vcg
>
> --
> yongchong
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>


-- 
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to