GCC 7.2 Release Candidate available from gcc.gnu.org
A release candidate for GCC 7.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/gcc-7.2-RC-20170802/ and shortly its mirrors. It has been generated from SVN revision 250819. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 7.2 on Tuesday, August 8th.
Re: How to migrate struct rtl_opt_pass to class for GCC v6.x?
/opt/gcc-6.3/bin/gcc -fplugin=./dragonegg.so test/hello.c -wrapper
gdb,--args
GNU gdb (GDB) Fedora 7.12.1-48.fc25
...
Reading symbols from
/opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1...done.
(gdb) b /data/project/xiangzhai/gcc-6.3.0/gcc/passes.c:2288
Breakpoint 1 at 0x91b8d4: file ../../gcc/passes.c, line 2288.
(gdb) r
Starting program:
/opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1 -quiet
-iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux-gnu/6.3.0/plugin
test/hello.c
-iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux-gnu/6.3.0/plugin
-quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello
-fplugin=./dragonegg.so -o /tmp/cco7mKtB.s
...
Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c7b730) at
../../gcc/passes.c:2288
warning: Source file is more recent than executable.
2288 current_pass = pass;
(gdb) p pass
$1 = (opt_pass *) 0x1c7b730
(gdb) p current_pass
$2 = (opt_pass *) 0x0
(gdb) n
2292 gate_status = pass->gate (cfun);
(gdb) p current_pass
$3 = (opt_pass *) 0x1c7b730
(gdb) p gate_status
$4 = false
(gdb) n
2293 gate_status = override_gate_status (pass,
current_function_decl, gate_status);
(gdb) p gate_status
$5 = false
(gdb) n
2292 gate_status = pass->gate (cfun);
(gdb) p gate_status
$6 = false
(gdb) n
2293 gate_status = override_gate_status (pass,
current_function_decl, gate_status);
(gdb) n
2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);
(gdb) p gate_status
$7 = true
(gdb) n
2293 gate_status = override_gate_status (pass,
current_function_decl, gate_status);
(gdb) n
2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status);
(gdb) n
2298 if (!gate_status)
(gdb) p gate_status
$8 = true
(gdb) n
...
(gdb) n
2336 todo_after = pass->execute (cfun); <--- gcc called execute hook?
(gdb) p todo_after
$9 = 0
(gdb) n
2338 if (todo_after & TODO_discard_function)
(gdb) p todo_after
$10 = 0
(gdb)
2336 todo_after = pass->execute (cfun); <--- gcc called execute
hook? but why not dragonegg
https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Backend.cpp#L2103
在 2017年08月03日 11:24, Leslie Zhai 写道:
Hi GCC developers,
As ChangeLog-2013 mentioned:
2013-08-05 David Malcolm
This is the automated part of the conversion of passes from C
structs to C++ classes.
...
* auto-inc-dec.c (pass_inc_dec): Convert from a global struct to a
subclass of rtl_opt_pass along with...
so I migrate struct rtl_opt_pass:
https://github.com/llvm-mirror/dragonegg/blob/master/src/Backend.cpp#L1731
static struct rtl_opt_pass pass_rtl_emit_function = { {
RTL_PASS, "rtl_emit_function", /* name */
#if (GCC_MINOR > 7)
OPTGROUP_NONE, /* optinfo_flags */
#endif
NULL, /* gate */
rtl_emit_function, /* execute */
NULL, /* sub */
NULL, /* next */
0, /* static_pass_number */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts, /*
todo_flags_start */
TODO_ggc_collect /* todo_flags_finish */
} };
to GCC v6.x C++ classes' style:
https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Backend.cpp#L2072
const pass_data pass_data_rtl_emit_function = {
RTL_PASS, /* type */
"rtl_emit_function", /* name */
OPTGROUP_NONE, /* optinfo_flags */
TV_NONE, /* tv_id */
PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
0, /* properties_provided */
PROP_ssa | PROP_trees, /* properties_destroyed */
0, /* todo_flags_start */
0, /* todo_flags_finish */
};
class pass_rtl_emit_function : public rtl_opt_pass {
public:
pass_rtl_emit_function(gcc::context *ctxt)
: rtl_opt_pass(pass_data_rtl_emit_function, ctxt) {}
unsigned int execute(function *) { return rtl_emit_function(); }
opt_pass *clone() { return this; }
};
GCC v4.6 will call the callback `rtl_emit_function`, but GCC v6.x will
not, did I forget something? is there some options need to be set?
please give me some hint, thanks a lot!
PS: GCC v6.x *call* the callback `rtl_emit_function`
https://github.com/xiangzhai/dragonball/blob/master/tests/plugin.cpp#L67
in this testcase, I will check the source code about
register_callback, rtl_opt_pass, and opt_pass.
--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/
Re: [patch] RFC: Hook for insn costs?
On Wed, Aug 02, 2017 at 12:56:58PM -0700, Richard Henderson wrote:
> On 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> > I'm not sure if that's a good or a bad thing. Currently the mid-end
> > depends on some rtx constructs having sensible costs even if there's no
> > rtl pattern to match them (IIRC plus:QI is one such construct - RISC
> > type machines usually lack such an instruction).
>
> I hadn't considered this... but there are several possible workarounds.
>
> The simplest of which is to fall back to using rtx_cost if the insn_cost hook
> returns a failure indication, e.g. -1.
>
> > Also, costs tend to be
> > micro-architecture specific so attaching costs directly to patterns
> > would be extremely painful, adding support would require touching the
> > entirety of the MD files. The best bet would be a level of indirection
> > from the patterns to cost tables, much like scheduler attributes.
>
> I was never thinking of adding costs directly to the md files, but rather
> structuring the insn_cost hook like
>
> if (recog_memoized (insn) < 0)
> return -1;
> switch (get_attr_type (insn))
> {
> case TYPE_iadd:
> case TYPE_ilog:
> case TYPE_mvi:
> return COSTS_N_INSNS (1);
>
> case TYPE_fadd:
> return cost_data->fp_add;
> }
>
> etc. This would be especially important when it comes costing for simd-type
> insns. Matching many of those any other way would be fraught with peril.
I tried prototyping something like this for AArch64 a while back - it
feels like the only sensible, scalable and maintainable way to rationalise
the costs code. Anything else drifts from the md file over time, and is
a tangled mess of spaghetti code to implement a poor-quality recog clone.
I ran in to exactly the problem Richard Earnshaw mentions above - too
many partial rtx fragments came in that I couldn't recognise. The points
in the compilation pipeline where I could receive an RTX to cost meant that
I could get be asked for costs before recog was correctly initialised.
I think a clean hook which operated in this way would be a great step
forward for the RTX costs.
Thanks,
James
Re: Overwhelmed by GCC frustration
On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherrill wrote: > > Long ago, there was a code size regression tester for at least > ARM. Is that still around? There used to be autotesters from CSiBE. Something still appears to exist (http://www.csibe.org/old/) but the last time I tried to run the benchmark, I couldn't get the suite to compile. That was some years ago, perhaps the situation is better nowadays (http://www.csibe.org/ without the old, suggests something's changed at some point...). As for "long ago", see also your own reply to https://gcc.gnu.org/ml/gcc/2003-07/msg00111.html :-) Ciao! Steven
Re: How to migrate struct rtl_opt_pass to class for GCC v6.x?
On Thu, 2017-08-03 at 17:21 +0800, Leslie Zhai wrote:
> /opt/gcc-6.3/bin/gcc -fplugin=./dragonegg.so test/hello.c -wrapper
> gdb,--args
> GNU gdb (GDB) Fedora 7.12.1-48.fc25
> ...
> Reading symbols from
> /opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1...done.
> (gdb) b /data/project/xiangzhai/gcc-6.3.0/gcc/passes.c:2288
> Breakpoint 1 at 0x91b8d4: file ../../gcc/passes.c, line 2288.
> (gdb) r
> Starting program:
> /opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1 -quiet
> -iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux-
> gnu/6.3.0/plugin
> test/hello.c
> -iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux-
> gnu/6.3.0/plugin
> -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello
> -fplugin=./dragonegg.so -o /tmp/cco7mKtB.s
> ...
>
> Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c7b730) at
> ../../gcc/passes.c:2288
> warning: Source file is more recent than executable.
This warning is somewhat unnerving; have you updated the source code
for the compiler since you last recompiled it?
> 2288 current_pass = pass;
>
> (gdb) p pass
> $1 = (opt_pass *) 0x1c7b730
> (gdb) p current_pass
> $2 = (opt_pass *) 0x0
> (gdb) n
> 2292 gate_status = pass->gate (cfun);
> (gdb) p current_pass
> $3 = (opt_pass *) 0x1c7b730
> (gdb) p gate_status
> $4 = false
> (gdb) n
> 2293 gate_status = override_gate_status (pass,
> current_function_decl, gate_status);
> (gdb) p gate_status
> $5 = false
> (gdb) n
> 2292 gate_status = pass->gate (cfun);
> (gdb) p gate_status
> $6 = false
> (gdb) n
> 2293 gate_status = override_gate_status (pass,
> current_function_decl, gate_status);
> (gdb) n
> 2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE,
> &gate_status);
> (gdb) p gate_status
> $7 = true
> (gdb) n
> 2293 gate_status = override_gate_status (pass,
> current_function_decl, gate_status);
> (gdb) n
> 2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE,
> &gate_status);
> (gdb) n
> 2298 if (!gate_status)
> (gdb) p gate_status
> $8 = true
> (gdb) n
> ...
> (gdb) n
> 2336 todo_after = pass->execute (cfun); <--- gcc called execute
> hook?
Try "step" here rather than "n" for "next"; that way you can see
exactly what is being called.
I had a hunch that you might be running into the default implementation
of opt_pass::execute, which is a no-op.
opt_pass::execute used to take "void", but was changed to take a
"function *" in r209482 (aka 65b0537f9e9741318f7c8e738b6dd3b8f82f58b5)
on 2014-04-17. If you're using a >= C++11 compiler, you might want to
try adding "final override" to the execute method of your pass to
ensure that it's an override of the execute virtual function. We have
macros "FINAL" and "OVERRIDE" for this in recent versions of gcc.
Is this definitely the correct pass? What does
(gdb) p *pass
print?
Dave
> (gdb) p todo_after
> $9 = 0
> (gdb) n
> 2338 if (todo_after & TODO_discard_function)
> (gdb) p todo_after
> $10 = 0
> (gdb)
>
>
> 2336 todo_after = pass->execute (cfun); <--- gcc called execute
> hook? but why not dragonegg
> https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Backen
> d.cpp#L2103
>
>
>
> 在 2017年08月03日 11:24, Leslie Zhai 写道:
> > Hi GCC developers,
> >
> > As ChangeLog-2013 mentioned:
> >
> > 2013-08-05 David Malcolm
> >
> > This is the automated part of the conversion of passes from C
> > structs to C++ classes.
> >
> > ...
> >
> > * auto-inc-dec.c (pass_inc_dec): Convert from a global struct
> > to a
> > subclass of rtl_opt_pass along with...
> >
> >
> > so I migrate struct rtl_opt_pass:
> > https://github.com/llvm-mirror/dragonegg/blob/master/src/Backend.cp
> > p#L1731
> >
> >
> > static struct rtl_opt_pass pass_rtl_emit_function = { {
> > RTL_PASS, "rtl_emit_function", /* name */
> > #if (GCC_MINOR > 7)
> > OPTGROUP_NONE, /* optinfo_flags */
> > #endif
> > NULL, /* gate */
> > rtl_emit_function, /* execute */
> > NULL, /* sub */
> > NULL, /* next */
> > 0, /* static_pass_number */
> > TV_NONE, /* tv_id */
> > PROP_ssa | PROP_gimple_leh | PROP_cfg, /* properties_required */
> > 0, /* properties_provided */
> > PROP_ssa | PROP_trees, /* properties_destroyed */
> > TODO_verify_ssa | TODO_verify_flow | TODO_verify_stmts, /*
> > todo_flags_start */
> > TODO_ggc_collect /* todo_flags_finish */
> > } };
> >
> >
> > to GCC v6.x C++ classes' style:
> > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Back
> > end.cpp#L2072
> >
> >
> > const pass_data pass_data_rtl_emit_function = {
> > RTL_PASS, /* type */
> > "rtl_emit_function", /* name */
> > OPTGROUP_NONE,
Re: RFC: C extension to support variable-length vector types
On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: > Torvald Riegel writes: > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: > >> (1) Does the approach seem reasonable? > >> > >> (2) Would it be acceptable in principle to add this extension to the > >> GCC C frontend (only enabled where necessary)? > >> > >> (3) Should we submit this to the standards committee? > > > > I hadn't have time to look at the proposal in detail. I think it would > > be good to have the standards committees review this. I doubt you could > > find consensus in the C++ for type system changes unless you have a > > really good reason. Have you considered how you could use the ARM > > extensions from http://wg21.link/p0214r4 ? > > Yeah, we've been following that proposal, but I don't think it helps > as-is with SVE. datapar is "an array of target-specific size, > with elements of type T, ..." and for SVE the natural target-specific > size would be a runtime value. The core language would still need to > provide a way of creating that array. I think the actual data will have a size -- your proposal seems to try to express a control structure (ie, SIMD / loop-like) by changing the type system. This seems odd to me. Why can't you keep the underlying data have a size (ie, be an array), and change your operations to work on arrays or slices of arrays? That won't help with automatic-storage-duration variables that one would need as temporaries, but perhaps it would be better to let programmers declare these variables as large vectors and have the compiler figure out what size they really need to be if only accessed through the SVE operations as temporary storage? > Similarly to other vector architectures (including AdvSIMD), the SVE > intrinsics and their types are more geared towards people who want > to optimise specifically for SVE without having to resort to assembly. > That's an important use case for us, and I think there's always going to > be a need for it alongside generic SIMD and parallel-programming models > (which of course are a good thing to have too). > > Being able to use SVE features from C is also important. Not all > projects are prepared to convert to C++. I'd doubt that the sizeless types would find consensus in the C++ committee. The C committee may perhaps be more open to that, given that C is more restricted and thus has to use language extensions more often. If they don't find uptake in ISO C/C++, this will always be a vendor-specific thing. You seem to say that this may be okay for you, but are there enough non-library-implementer developers out there that would use it to justify extending the type system?
Re: RFC: C extension to support variable-length vector types
On Thu, 2017-08-03 at 17:32 +0200, Torvald Riegel wrote: > On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: > > Torvald Riegel writes: > > > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: > > >> (1) Does the approach seem reasonable? > > >> > > >> (2) Would it be acceptable in principle to add this extension to the > > >> GCC C frontend (only enabled where necessary)? > > >> > > >> (3) Should we submit this to the standards committee? > > > > > > I hadn't have time to look at the proposal in detail. I think it would > > > be good to have the standards committees review this. I doubt you could > > > find consensus in the C++ for type system changes unless you have a > > > really good reason. Have you considered how you could use the ARM > > > extensions from http://wg21.link/p0214r4 ? BTW, have you also looked at P0546 and P0122?
Re: RFC: C extension to support variable-length vector types
On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel wrote: >On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: >> Torvald Riegel writes: >> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: >> >> (1) Does the approach seem reasonable? >> >> >> >> (2) Would it be acceptable in principle to add this extension to >the >> >> GCC C frontend (only enabled where necessary)? >> >> >> >> (3) Should we submit this to the standards committee? >> > >> > I hadn't have time to look at the proposal in detail. I think it >would >> > be good to have the standards committees review this. I doubt you >could >> > find consensus in the C++ for type system changes unless you have a >> > really good reason. Have you considered how you could use the ARM >> > extensions from http://wg21.link/p0214r4 ? >> >> Yeah, we've been following that proposal, but I don't think it helps >> as-is with SVE. datapar is "an array of target-specific size, >> with elements of type T, ..." and for SVE the natural target-specific >> size would be a runtime value. The core language would still need to >> provide a way of creating that array. > >I think the actual data will have a size -- your proposal seems to try >to express a control structure (ie, SIMD / loop-like) by changing the >type system. This seems odd to me. >Why can't you keep the underlying data have a size (ie, be an array), >and change your operations to work on arrays or slices of arrays? That >won't help with automatic-storage-duration variables that one would >need >as temporaries, but perhaps it would be better to let programmers >declare these variables as large vectors and have the compiler figure >out what size they really need to be if only accessed through the SVE >operations as temporary storage? Btw., I did this once to represent constrained expressions on multi-dimensional arrays in SSA form. There control (aka loop) structure was also implicit. Google for 'middle-end array expressions'. The C interface was builtins and VLAs. Richard. >> Similarly to other vector architectures (including AdvSIMD), the SVE >> intrinsics and their types are more geared towards people who want >> to optimise specifically for SVE without having to resort to >assembly. >> That's an important use case for us, and I think there's always going >to >> be a need for it alongside generic SIMD and parallel-programming >models >> (which of course are a good thing to have too). >> >> Being able to use SVE features from C is also important. Not all >> projects are prepared to convert to C++. > >I'd doubt that the sizeless types would find consensus in the C++ >committee. The C committee may perhaps be more open to that, given >that >C is more restricted and thus has to use language extensions more >often. > >If they don't find uptake in ISO C/C++, this will always be a >vendor-specific thing. You seem to say that this may be okay for you, >but are there enough non-library-implementer developers out there that >would use it to justify extending the type system?
Re: [patch] RFC: Hook for insn costs?
On 08/02/2017 01:34 PM, Richard Earnshaw wrote: > On 26/07/17 18:54, Jeff Law wrote: >> On 07/17/2017 02:35 PM, Richard Henderson wrote: >>> On 07/17/2017 12:20 AM, Richard Biener wrote: On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool > Now what should it take as input? An rtx_insn, or just the pattern > (as insn_rtx_cost does)? Is there any useful info on the other operands of an rtx_insn? If not then passing in the pattern (a rtx) might be somewhat more flexible. Of course it's then way easier to confuse rtx_cost and insn_cost ... >>> >>> A lot of really complex by-hand pattern matching goes away if you know >>> the instruction is valid, and you can look up an insn attribute. That >>> suggests passing the insn and not the PATTERN. >> Good point. In fact, it opens the possibility that costing could be >> attached to the insn itself as just another attribute if it made sense >> for the target to describe costing in that manner. >> >> Jeff >> > > I'm not sure if that's a good or a bad thing. I haven't really though much about it and I certainly wouldn't push for it as a direction without further investigation. It's just one thing that could be possible if we though it made sense. jeff
Re: RFC: C extension to support variable-length vector types
On August 3, 2017 5:51:35 PM GMT+02:00, Richard Biener wrote: >On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel > wrote: >>On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: >>> Torvald Riegel writes: >>> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote: >>> >> (1) Does the approach seem reasonable? >>> >> >>> >> (2) Would it be acceptable in principle to add this extension >to >>the >>> >> GCC C frontend (only enabled where necessary)? >>> >> >>> >> (3) Should we submit this to the standards committee? >>> > >>> > I hadn't have time to look at the proposal in detail. I think it >>would >>> > be good to have the standards committees review this. I doubt you >>could >>> > find consensus in the C++ for type system changes unless you have >a >>> > really good reason. Have you considered how you could use the ARM >>> > extensions from http://wg21.link/p0214r4 ? >>> >>> Yeah, we've been following that proposal, but I don't think it helps >>> as-is with SVE. datapar is "an array of target-specific size, >>> with elements of type T, ..." and for SVE the natural >target-specific >>> size would be a runtime value. The core language would still need >to >>> provide a way of creating that array. >> >>I think the actual data will have a size -- your proposal seems to try >>to express a control structure (ie, SIMD / loop-like) by changing the >>type system. This seems odd to me. >>Why can't you keep the underlying data have a size (ie, be an array), >>and change your operations to work on arrays or slices of arrays? >That >>won't help with automatic-storage-duration variables that one would >>need >>as temporaries, but perhaps it would be better to let programmers >>declare these variables as large vectors and have the compiler figure >>out what size they really need to be if only accessed through the SVE >>operations as temporary storage? > >Btw., I did this once to represent constrained expressions on >multi-dimensional arrays in SSA form. There control (aka loop) >structure was also implicit. Google for 'middle-end array >expressions'. The C interface was builtins and VLAs. So the point was that at the C source level the temporaries were simple scalars And the middle-end uses the built-in functions as source/sinks to transform them accordingly. So maybe scalars can be used for SVE as well. Richard. >Richard. > >>> Similarly to other vector architectures (including AdvSIMD), the SVE >>> intrinsics and their types are more geared towards people who want >>> to optimise specifically for SVE without having to resort to >>assembly. >>> That's an important use case for us, and I think there's always >going >>to >>> be a need for it alongside generic SIMD and parallel-programming >>models >>> (which of course are a good thing to have too). >>> >>> Being able to use SVE features from C is also important. Not all >>> projects are prepared to convert to C++. >> >>I'd doubt that the sizeless types would find consensus in the C++ >>committee. The C committee may perhaps be more open to that, given >>that >>C is more restricted and thus has to use language extensions more >>often. >> >>If they don't find uptake in ISO C/C++, this will always be a >>vendor-specific thing. You seem to say that this may be okay for you, >>but are there enough non-library-implementer developers out there that >>would use it to justify extending the type system?
Re: RFC [testsuite] Obey --load-average
On 08/02/2017 11:34 PM, Daniel Santos wrote:
> I'm working on a patch to modify the testsuite to obey the
> --load-average value if one is passed to make. It seems to work pretty
> well, except for libstdc++ which doesn't load gcc/libs/gcc-defs.exp
> since it defines it's own ${tool}_functions. I haven't dug too deeply
> into libstdc++'s testsuite yet, but how does it manage parallelization
> if it isn't using the routines in gcc-defs.exp? I'm thinking I will
> need a separate load-limit.exp file or some such.
>
> This feature would be very helpful since you cannot interrupt a test run
> and restart from where you left off. Also, if you suspend the job, then
> you will get timeouts. So it would be helpful to have a way to have it
> yield when you need to do something else on your machine, or if you're
> using a shared test machine and you want to use all available CPU, but
> not crowd out other users.
>
> Due to not having actual interprocess communication, the check_cpu_load
> procedure uses an algo that gives lower numbered jobs slightly more
> priority than higher numbered jobs. When the load average is exceeded,
> the job sleeps an amount of time based upon the "priority" (lower
> numbered jobs sleep less) and a random number - this helps prevent feast
> or famine cycles where all jobs stop when the load is too high and then
> all jobs start again and saturate the CPUs, bouncing back and forth.
>
> gcc/testsuite/ChangeLog
>
> * gcc/Makefile.in (check-parallel-%): Export job number to environment.
> * gcc/testsuite/lib/gcc-defs.exp (num_jobs, load_max, getloadavg_exe):
> New global variables.
> (check_cpu_load): New proc to check speed limit.
> (gcc_parallel_test_run_p): Modify to call check_cpu_load before
> acquiring a new lock file.
So does this perform better than make -j X -l X? I use that with good
success.
jeff
Re: RFC: C extension to support variable-length vector types
Torvald Riegel writes:
> On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>> Torvald Riegel writes:
>> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
>> >> (1) Does the approach seem reasonable?
>> >>
>> >> (2) Would it be acceptable in principle to add this extension to the
>> >> GCC C frontend (only enabled where necessary)?
>> >>
>> >> (3) Should we submit this to the standards committee?
>> >
>> > I hadn't have time to look at the proposal in detail. I think it would
>> > be good to have the standards committees review this. I doubt you could
>> > find consensus in the C++ for type system changes unless you have a
>> > really good reason. Have you considered how you could use the ARM
>> > extensions from http://wg21.link/p0214r4 ?
>>
>> Yeah, we've been following that proposal, but I don't think it helps
>> as-is with SVE. datapar is "an array of target-specific size,
>> with elements of type T, ..." and for SVE the natural target-specific
>> size would be a runtime value. The core language would still need to
>> provide a way of creating that array.
>
> I think the actual data will have a size -- your proposal seems to try
> to express a control structure (ie, SIMD / loop-like) by changing the
> type system. This seems odd to me.
>
> Why can't you keep the underlying data have a size (ie, be an array),
> and change your operations to work on arrays or slices of arrays? That
> won't help with automatic-storage-duration variables that one would need
> as temporaries, but perhaps it would be better to let programmers
> declare these variables as large vectors and have the compiler figure
> out what size they really need to be if only accessed through the SVE
> operations as temporary storage?
The types only really exist for objects of automatic storage duration
and for passing to and returning from functions. Like you say, the
original input and final result will be normal arrays.
For example, the vector function underlying:
#pragma omp declare simd
double sin(double);
would be:
svfloat64_t mangled_sin(svfloat64_t, svbool_t);
(The svbool_t is because SVE functions should be predicated by default,
to avoid the need for a scalar tail.)
These svfloat64_t and svbool_t types have no fixed size at compile time:
they represent one SVE register's worth of data, however big that register
happens to be. Making datapar be an array of a specific size would
make it unsuitable here.
To put it another way: the calling conventions do have the concept
of a register-sized vector that can be passed and returned efficiently.
These ACLE types are the C manifestations of those register-sized ABI types.
If instead we said that SVE vectors should be implicitly extracted from
a larger array, the ABI type would not have a direct representation in C.
I can't think of another case where that's true.
Leaving aside the question of vector library functions, if functions
used arrays for temporary results, and the ACLE intrinsics only operated
on slices of those arrays, it wouldn't always be obvious how big the
arrays should be. For example, here's a naive ACLE implementation of a
step-1 daxpy (quoting only to show the use of the types, since a
walkthrough of the behaviour might be off-topic):
void daxpy_1_1(int64_t n, double da, double *dx, double *dy)
{
int64_t i = 0;
svbool_t pg = svwhilelt_b64(i, n);
do
{
svfloat64_t dx_vec = svld1(pg, &dx[i]);
svfloat64_t dy_vec = svld1(pg, &dy[i]);
svst1(pg, &dy[i], svmla_x(pg, dy_vec, dx_vec, da));
i += svcntd();
pg = svwhilelt_b64(i, n);
}
while (svptest_any(svptrue_b64(), pg));
}
This isn't a good motivating example for why the ACLE is needed,
since the compiler ought to produce similar code from a simple scalar loop.
But if you were writing a less naive implementation for SVE, it would use
the ACLE in a similar way.
The point is that this implementation supports any vector length.
There's no hard limit on the size of the temporaries.
A perhaps more useful example is a naive implementation of a loop that
converts non-printable ASCII characters to '.' (obviously not a common
time-critical operation, but it has the advantage of being short and
using a few SVE-specific features):
void f(uint8_t *a)
{
svbool_t trueb = svptrue_b8();
svuint8_t dots = svdup_u8('.');
svbool_t terminators;
do
{
svwrffr(trueb);
svuint8_t data = svldff1(trueb, a);
svbool_t ld_mask = svrdffr();
svbool_t nonascii = svcmplt(ld_mask, data, ' '-1);
terminators = svcmpeq(ld_mask, data, 0);
svbool_t st_mask = svbrkb_z(nonascii, terminators);
svst1(st_mask, a, dots);
a += svcntp_b8(trueb, ld_mask);
}
while (!svptest_any(trueb, terminators));
}
Again, a walkthrough of the code might be off-topic, but the point
is tha
Re: RFC: C extension to support variable-length vector types
On August 3, 2017 7:05:05 PM GMT+02:00, Richard Sandiford
wrote:
>Torvald Riegel writes:
>> On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>>> Torvald Riegel writes:
>>> > On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
>>> >> (1) Does the approach seem reasonable?
>>> >>
>>> >> (2) Would it be acceptable in principle to add this extension
>to the
>>> >> GCC C frontend (only enabled where necessary)?
>>> >>
>>> >> (3) Should we submit this to the standards committee?
>>> >
>>> > I hadn't have time to look at the proposal in detail. I think it
>would
>>> > be good to have the standards committees review this. I doubt you
>could
>>> > find consensus in the C++ for type system changes unless you have
>a
>>> > really good reason. Have you considered how you could use the ARM
>>> > extensions from http://wg21.link/p0214r4 ?
>>>
>>> Yeah, we've been following that proposal, but I don't think it helps
>>> as-is with SVE. datapar is "an array of target-specific size,
>>> with elements of type T, ..." and for SVE the natural
>target-specific
>>> size would be a runtime value. The core language would still need
>to
>>> provide a way of creating that array.
>>
>> I think the actual data will have a size -- your proposal seems to
>try
>> to express a control structure (ie, SIMD / loop-like) by changing the
>> type system. This seems odd to me.
>>
>> Why can't you keep the underlying data have a size (ie, be an array),
>> and change your operations to work on arrays or slices of arrays?
>That
>> won't help with automatic-storage-duration variables that one would
>need
>> as temporaries, but perhaps it would be better to let programmers
>> declare these variables as large vectors and have the compiler figure
>> out what size they really need to be if only accessed through the SVE
>> operations as temporary storage?
>
>The types only really exist for objects of automatic storage duration
>and for passing to and returning from functions. Like you say, the
>original input and final result will be normal arrays.
>
>For example, the vector function underlying:
>
>#pragma omp declare simd
>double sin(double);
>
>would be:
>
>svfloat64_t mangled_sin(svfloat64_t, svbool_t);
>
>(The svbool_t is because SVE functions should be predicated by default,
>to avoid the need for a scalar tail.)
>
>These svfloat64_t and svbool_t types have no fixed size at compile
>time:
>they represent one SVE register's worth of data, however big that
>register
>happens to be. Making datapar be an array of a specific size would
>make it unsuitable here.
>
>To put it another way: the calling conventions do have the concept
>of a register-sized vector that can be passed and returned efficiently.
>These ACLE types are the C manifestations of those register-sized ABI
>types.
>If instead we said that SVE vectors should be implicitly extracted from
>a larger array, the ABI type would not have a direct representation in
>C.
>I can't think of another case where that's true.
>
>Leaving aside the question of vector library functions, if functions
>used arrays for temporary results, and the ACLE intrinsics only
>operated
>on slices of those arrays, it wouldn't always be obvious how big the
>arrays should be. For example, here's a naive ACLE implementation of a
>step-1 daxpy (quoting only to show the use of the types, since a
>walkthrough of the behaviour might be off-topic):
>
>void daxpy_1_1(int64_t n, double da, double *dx, double *dy)
>{
> int64_t i = 0;
> svbool_t pg = svwhilelt_b64(i, n);
> do
>{
> svfloat64_t dx_vec = svld1(pg, &dx[i]);
> svfloat64_t dy_vec = svld1(pg, &dy[i]);
> svst1(pg, &dy[i], svmla_x(pg, dy_vec, dx_vec, da));
> i += svcntd();
> pg = svwhilelt_b64(i, n);
>}
> while (svptest_any(svptrue_b64(), pg));
>}
Int64_t I;
Float DX = SVE_load (&I, &DX[0], n);
Float dy = SVE_load (&I, &dy[0], n);
SVE_store (&dy[0], DX * a + dy);
The &I args to the load would be optional in case you need the active lane
somewhere. So the scalar temporary 'middle-end array' way would be a data
parallel programming paradigm.
For ABI purposes I suggest to use attributes on the function to change scalars
to SVE vectors.
Using scalars has the advantage that regular optimizations can be applied,
Inlining works and that you can easily lower this to scalar or other
architectures vector code.
With vectors this is also way easier than with strided multi-dimensiomal arrays
;)
(Sorry for typos, writing this in my mobile phone...).
Richard.
>
>This isn't a good motivating example for why the ACLE is needed,
>since the compiler ought to produce similar code from a simple scalar
>loop.
>But if you were writing a less naive implementation for SVE, it would
>use
>the ACLE in a similar way.
>
>The point is that this implementation supports any vector length.
>There's no hard limit on the size of the tempor
Re: RFC [testsuite] Obey --load-average
On Aug 2, 2017, at 10:34 PM, Daniel Santos wrote: > > I'm working on a patch to modify the testsuite to obey the > --load-average value if one is passed to make. The code seems like a reasonable approach. Love to see numbers and test scenarios so that others can tell if you've covered their use case. -j 100 is different from -j 4. People can help chip in numbers, if they have senarios that are less represented. I don't usually share or use -l, so I don't think I can help test it. I do wonder if it might be better to use a higher -j (I use -j somewhere between 24 and 50) and use a load limit, even in my situation. The only concern would be that of portability. Seems reasonable to let it in and fix up any issues found after the fact. I like how you ensure low impact when -l isn't used. Minor nit, tollerance -> tolerance.
Re: How to migrate struct rtl_opt_pass to class for GCC v6.x?
Hi David, Thanks for your kind response! 在 2017年08月03日 21:54, David Malcolm 写道: On Thu, 2017-08-03 at 17:21 +0800, Leslie Zhai wrote: /opt/gcc-6.3/bin/gcc -fplugin=./dragonegg.so test/hello.c -wrapper gdb,--args GNU gdb (GDB) Fedora 7.12.1-48.fc25 ... Reading symbols from /opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1...done. (gdb) b /data/project/xiangzhai/gcc-6.3.0/gcc/passes.c:2288 Breakpoint 1 at 0x91b8d4: file ../../gcc/passes.c, line 2288. (gdb) r Starting program: /opt/gcc-6.3/libexec/gcc/x86_64-redhat-linux-gnu/6.3.0/cc1 -quiet -iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux- gnu/6.3.0/plugin test/hello.c -iplugindir=/opt/gcc-6.3/lib/gcc/x86_64-redhat-linux- gnu/6.3.0/plugin -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -fplugin=./dragonegg.so -o /tmp/cco7mKtB.s ... Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c7b730) at ../../gcc/passes.c:2288 warning: Source file is more recent than executable. This warning is somewhat unnerving; have you updated the source code for the compiler since you last recompiled it? The warning disappeared after recompiled GCC v6.3 2288 current_pass = pass; (gdb) p pass $1 = (opt_pass *) 0x1c7b730 (gdb) p current_pass $2 = (opt_pass *) 0x0 (gdb) n 2292 gate_status = pass->gate (cfun); (gdb) p current_pass $3 = (opt_pass *) 0x1c7b730 (gdb) p gate_status $4 = false (gdb) n 2293 gate_status = override_gate_status (pass, current_function_decl, gate_status); (gdb) p gate_status $5 = false (gdb) n 2292 gate_status = pass->gate (cfun); (gdb) p gate_status $6 = false (gdb) n 2293 gate_status = override_gate_status (pass, current_function_decl, gate_status); (gdb) n 2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status); (gdb) p gate_status $7 = true (gdb) n 2293 gate_status = override_gate_status (pass, current_function_decl, gate_status); (gdb) n 2296 invoke_plugin_callbacks (PLUGIN_OVERRIDE_GATE, &gate_status); (gdb) n 2298 if (!gate_status) (gdb) p gate_status $8 = true (gdb) n ... (gdb) n 2336 todo_after = pass->execute (cfun); <--- gcc called execute hook? Try "step" here rather than "n" for "next"; that way you can see exactly what is being called. I had a hunch that you might be running into the default implementation of opt_pass::execute, which is a no-op. opt_pass::execute used to take "void", but was changed to take a "function *" in r209482 (aka 65b0537f9e9741318f7c8e738b6dd3b8f82f58b5) on 2014-04-17. If you're using a >= C++11 compiler, you might want to try adding "final override" to the execute method of your pass to ensure that it's an override of the execute virtual function. We have macros "FINAL" and "OVERRIDE" for this in recent versions of gcc. Add as your suggestion. https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Backend.cpp#L2110 Is this definitely the correct pass? What does (gdb) p *pass print? Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c7b730) at ../../gcc/passes.c:2288 2288 current_pass = pass; ... (gdb) p pass->name $1 = 0x11a2369 "*warn_unused_result" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86270) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $2 = 0x1181b98 "*diagnose_omp_blocks" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c862d0) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $3 = 0x119d740 "*diagnose_tm_blocks" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86330) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $4 = 0x1181bad "omplower" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86390) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $5 = 0x11be968 "lower" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c863f0) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $6 = 0x119d738 "tmlower" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86450) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $7 = 0x11a711e "ehopt" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c864b0) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $8 = 0x119b9cf "eh" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86510) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $9 = 0x11972bb "cfg" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c86570) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $10 = 0x11a237d "*warn_function_return" (gdb) c Continuing. Breakpoint 1, execute_one_pass (pass=pass@entry=0x1c865d0) at ../../gcc/passes.c:2288 2288 current_pass = pass; (gdb) p pass->name $11 = 0x1181bc0 "o
