On Mon, 2013-07-29 at 14:01 -0600, Jeff Law wrote:
On 07/26/2013 09:04 AM, David Malcolm wrote:
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-instances.def contains similar content to passes.def,
but the pass instances within it are explicitly numbered, so that e.g.
the third instance of:
NEXT_PASS (pass_copy_prop)
becomes:
NEXT_PASS (pass_copy_prop, 3)
This is needed by a subsequent patch so that we can create fields within
the pipeline class for each pass instance, where we need unique field
names to avoid a syntax error. For example, all 8 instances of
pass_copy_prop will need different names. e.g.
opt_pass *pass_copy_prop_1;
...
opt_pass *pass_copy_prop_8;
I have successfully tested the script with gawk, with gawk using the
-c compatibility option to turn off gawk extensions, and with busybox
awk (versions tested were gawk-4.0.1 and busybox-1.19.4).
This patch replaces a previous attempt at this:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00686.html
which converted multi-instance passes to using a new NEXT_PASS_NUM
macro, requiring the instance numbering within passes.def to be
maintained by hand.
In the new approach, the instance numbers are generated automatically,
and are visible at build time, giving the uniqueness needed by later
patches, whilst avoiding manual maintenance work, and also making it
easy to see the instance numbering (by inspecting the generated
pass-instances.def).
gcc/
* Makefile.in (pass-instances.def): New.
(passes.o): Replace dependency on passes.def with one on
pass-instances.def
* gen-pass-instances.awk: New.
* passes.c (pipeline::pipeline): Use pass-instances.def rather
than passes.def, updating local definition of NEXT_PASS macro
to add an extra NUM parameter (currently unused).
My awk-fu isn't all that great. I'm going to assume this works and that
if it breaks, you own it :-)
Fine for the trunk.
Thanks.
Committed to trunk as r201359, having double-checked that it
bootstrapped by itself on top of what had gone before, and that the
testsuite results were unaffected by it (on x86_64-unknown-linux-gnu).
