Re: ira-loop-pressure not marked as optimization?
On 06/03/14 21:03, Vladimir Makarov wrote: On 03/06/2014 03:14 PM, Paulo J. Matos wrote: Still, would you accept a patch to mark this flag as an optimization? I think we should. Submitted to gcc-patches for approval. -- PMatos
gcc-4.8-20140306 is now available
Snapshot gcc-4.8-20140306 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140306/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 208386 You'll find: gcc-4.8-20140306.tar.bz2 Complete GCC MD5=21b4594573d5141afd2109b11037eb2c SHA1=81ea750ca467822ad5811ae0e5e92d4c781c2cd5 Diffs from 4.8-20140227 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[buildrobot] Ada/VMS code won't build
Hi Doug! Your recent VMS change committed by Arnaud Charlet won't build, see eg. build log [1] for build #154768 [2], which is targeted to alpha64-dec-vms: g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Iada -I../../../gcc/gcc -I../../../gcc/gcc/ada -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o ada/trans.o -MT ada/trans.o -MMD -MP -MF ada/.deps/trans.TPo ../../../gcc/gcc/ada/gcc-interface/trans.c ../../../gcc/gcc/ada/gcc-interface/trans.c: In function ‘void gigi(Node_Id, int, int, Node*, Flags*, Node_Id*, Node_Id*, Elist_Header*, Elmt_Item*, String_Entry*, Char_Code*, List_Header*, Nat, File_Info_Type*, Entity_Id, Entity_Id, Entity_Id, Entity_Id, Entity_Id, Int)’: ../../../gcc/gcc/ada/gcc-interface/trans.c:320:3: error: ‘vms_float_format’ was not declared in this scope vms_float_format = Float_Format; ^ make[2]: *** [ada/trans.o] Error 1 Actually, I cannot find `vms_float_format' anywhere, but I don't know the Ada code at all... Probably easy to fix? MfG, JBG [1] http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=1139497 [2] http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=154768 -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: "Debugging is twice as hard as writing the code in the first place. the second : Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan signature.asc Description: Digital signature
Re: ira-loop-pressure not marked as optimization?
On 06/03/14 21:03, Vladimir Makarov wrote: On 03/06/2014 03:14 PM, Paulo J. Matos wrote: I have just run a few long benchmarks and even though I had high expectations for improving performance the flag in our port causes a ~3% degradation in performance. Haven't had time to investigate why. Strange. What port is this? Can I see the benchmarks. I know Pat Haugen from IBM found a bug which can generated worse code in some cases and has a fix. I hope Pat submits it on stage 1. Vladimir, unfortunately I cannot send the benchmarks as they are private customer code. However, I will investigate the degradation and try to find a case which I can reduce and post on the list. The port is for an internal Broadcom chip, SIMD/VLIW sharing some similarities and technical issues from a compiler point of view as IA-64. Still, would you accept a patch to mark this flag as an optimization? I think we should. I will submit a patch to gcc-patches. Thanks, -- Paulo Matos
Re: ira-loop-pressure not marked as optimization?
On 03/06/2014 03:14 PM, Paulo J. Matos wrote: > On 06/03/14 15:15, Vladimir Makarov wrote: >> On 03/06/2014 08:55 AM, Paulo Matos wrote: >>> Hi, >>> >>> Upon noticing ira-hoist-pressure in `gcc --help=optimizers` and not >>> ira-loop-pressure, >>> I am wondering why the latter is not marked as an Optimization in >>> common.opt: >>> >>> fira-loop-pressure >>> Common Report Var(flag_ira_loop_pressure) >>> Use IRA based register pressure calculation >>> in RTL loop optimizations. >>> >>> Should we mark it as such? >>> >>> >> It is not an optimization strictly speaking. It is a better register >> pressure calculation used for invariant loop motion decisions. >> >> On the other hand, using this option can improve generated code >> performance (e.g. as I remember it improved SPECFP2000 by 1% for >> ppc64). So I guess, it should mark as such in order to see this >> possibility to improve the code by a programmer. >> >> > > I have just run a few long benchmarks and even though I had high > expectations for improving performance the flag in our port causes a > ~3% degradation in performance. Haven't had time to investigate why. > Strange. What port is this? Can I see the benchmarks. I know Pat Haugen from IBM found a bug which can generated worse code in some cases and has a fix. I hope Pat submits it on stage 1. > Still, would you accept a patch to mark this flag as an optimization? > I think we should.
Re: ira-loop-pressure not marked as optimization?
On 06/03/14 15:15, Vladimir Makarov wrote: On 03/06/2014 08:55 AM, Paulo Matos wrote: Hi, Upon noticing ira-hoist-pressure in `gcc --help=optimizers` and not ira-loop-pressure, I am wondering why the latter is not marked as an Optimization in common.opt: fira-loop-pressure Common Report Var(flag_ira_loop_pressure) Use IRA based register pressure calculation in RTL loop optimizations. Should we mark it as such? It is not an optimization strictly speaking. It is a better register pressure calculation used for invariant loop motion decisions. On the other hand, using this option can improve generated code performance (e.g. as I remember it improved SPECFP2000 by 1% for ppc64). So I guess, it should mark as such in order to see this possibility to improve the code by a programmer. I have just run a few long benchmarks and even though I had high expectations for improving performance the flag in our port causes a ~3% degradation in performance. Haven't had time to investigate why. Still, would you accept a patch to mark this flag as an optimization? -- PMatos
Re: Shouldn't unsafe-math-optimizations (re-)enable fp-contract=fast?
On 3/6/2014 1:01 PM, Joseph S. Myers wrote: On Thu, 6 Mar 2014, Ian Bolton wrote: Hi there, I see in common.opt that fp-contract=fast is the default for GCC. But then it gets disabled in c-family/c-opts.c if you are using ISO C (e.g. with -std=c99). But surely if you have also specified -funsafe-math-optimizations then it should flip it back onto fast? That seems reasonable. I do see an improvement in several benchmarks by use of fma when I append -ffp-contract=fast after -std=c99 Thanks. -- Tim Prince
Re: [gsoc 2014] moving fold-const patterns to gimple
On Thu, Mar 6, 2014 at 6:13 PM, Richard Biener
wrote:
> On Thu, Mar 6, 2014 at 1:11 PM, Prathamesh Kulkarni
> wrote:
>> On Mon, Mar 3, 2014 at 3:32 PM, Richard Biener
>> wrote:
>>> On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni
>>> wrote:
Hi, I am an undergraduate student at University of Pune, India, and would
like to work on moving folding patterns from fold-const.c to gimple.
>>>
>>> I've seen the entry on our GSoC project page and edited it to discourage
>>> people from working on that line. See
>>>
>>> http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
>>>
>>> for why. I think that open-coding the transforms isn't maintainable
>>> in the long run.
>>>
If I understand correctly, constant folding is done on GENERIC (by
routines in fold-const.c), and then GENERIC is lowered to GIMPLE. The
purpose of this project,
is to have constant folding to be performed on GIMPLE instead (in
gimple-fold.c?)
I have a few elementary questions to ask:
a) A contrived example:
Consider a C expression, a = ~0 (assume a is int)
In GENERIC, this would roughly be represented as:
modify_expr>>
this gets folded to:
modify_expr
and the corresponding gimple tuple generated is (-fdump-tree-gimple-raw):
gimple_assign
So, instead of folding performed on GENERIC, it should be
done on GIMPLE.
So a tuple like the following should be generated by gimplification:
and folded to (by call to fold_stmt):
Is this the expected behavior ?
I have attached a rough/incomplete patch (only stage1 compiled cc1), that
does the following foldings on bit_not_expr:
a) ~ INTEGER_CST => folded
b) ~~x => x
c) ~(-x) => x - 1
(For the moment, I put case BIT_NOT_EXPR: return NULL_TREE
in fold_unary_loc to avoid folding in GENERIC on bit_not_expr)
Is the patch going in the correct direction ? Or have I completely missed
the point here ? I would be grateful to receive suggestions, and start
working
on a fair patch.
>>>
>>> I think you implement what was suggested by Kai (and previously
>>> by me and Andrew, before I changed my mind).
>>>
>> Hi Richard,
>> Thanks for your reply and for pointing me out to this thread
>> http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
>>
>> I agree it's better to generate patterns from a meta-description
>> instead of hand-coding, and the idea seems interesting to me.
>>
>> I was playing around with the patch and did few trivial modifications
>> (please find the patch attached):
>> a) use obstack in parse_c_expr.
>>
>> b) use @ inside c code, instead of directly writing captures
>> (like $ in bison):
>> example:
>> /* Match and simplify CST + CST to CST'. */
>> (define_match_and_simplify baz
>> (PLUS_EXPR INTEGER_CST_P@0 INTEGER_CST_P@1)
>> { int_const_binop (PLUS_EXPR, @0, @1); })
>>
>> c) Not sure if this is a good idea, conditional matching.
>> for example:
>> /* match (A * B) and simplify to
>> * B if integer_zerop B is true ( A * 0 => 0)
>> * A if integer_onep B is true (A * 1 => A)
>> */
>> (define_match_and_simplify multexpr
>> (MULT_EXPR integral_op_p@0 integral_op_p@1)
>> [
>> (integer_zerop@1 @1)
>> (integer_onep@1 @0)
>> ])
>> Maybe condition can be generalized to be any operand instead of
>> testing predicate on capture operand ?
>>
>> I would be grateful to receive some direction for working on this project.
>> From the thread, I see a few possibilities:
>> a) Moving patterns from tree-ssa-forwprop
>> b) Extending the DSL (handle commutative operators, conditionally
>> enabling patterns ?)
>> c) Targeting GENERIC (Generating patterns in fold-const.c from the
>> description ?)
>> d) This is a bit silly, but maybe perform more error checking ?
>> for example the following pattern is currently accepted:
>> (define_match px
>> (PLUS_EXPR @0 @1 @2))
>
> Note that I'm currently still hacking on this (see attachment for what
> I have right now). The grammar is still in flux but I'd like to keep it
> simple for now (so no conditional replacement).
>
> I have changed quite some bits so d) should be easily possible
> now and I've done b) from your list as well.
>
> For the moment I'm trying to see whether the design is sound,
> especially the GCC-side APIs. I hope to finish this this week
> (fingers crossing), and also settle on the syntax (see variants in
> the .pd).
>
> As for opening this up for a GSOC project to "finish" or work on
> that's a good idea. In addition to a) Moving patterns from tree-ssa-forwprop
> which I think is the place where its easiest to plug this in without
> regressions it would be nice if you could work on e) Generate a
> state machine for the matching part, instead of trying one pattern
> after each other (see how insn-recog.c is produced). I hope to
> cleanup the parser AST implementation a bit so that b) handling
> of commutative ops is possible as a pattern-duplicat
Re: Shouldn't unsafe-math-optimizations (re-)enable fp-contract=fast?
On Thu, 6 Mar 2014, Ian Bolton wrote: > Hi there, > > I see in common.opt that fp-contract=fast is the default for GCC. > > But then it gets disabled in c-family/c-opts.c if you are using ISO C > (e.g. with -std=c99). > > But surely if you have also specified -funsafe-math-optimizations then > it should flip it back onto fast? That seems reasonable. -- Joseph S. Myers jos...@codesourcery.com
Shouldn't unsafe-math-optimizations (re-)enable fp-contract=fast?
Hi there, I see in common.opt that fp-contract=fast is the default for GCC. But then it gets disabled in c-family/c-opts.c if you are using ISO C (e.g. with -std=c99). But surely if you have also specified -funsafe-math-optimizations then it should flip it back onto fast? I see in gcc/opts.c that a few other flags are triggered based on -funsafe-math-optimizations but not -ffp-contract=fast. I think this is a bug and could lead to less optimal code than people would like if they want c99 compliance for reason A but also unsafe math for reason B. What do you think? Cheers, Ian
Re: ira-loop-pressure not marked as optimization?
On 03/06/2014 08:55 AM, Paulo Matos wrote: > Hi, > > Upon noticing ira-hoist-pressure in `gcc --help=optimizers` and not > ira-loop-pressure, > I am wondering why the latter is not marked as an Optimization in common.opt: > > fira-loop-pressure > Common Report Var(flag_ira_loop_pressure) > Use IRA based register pressure calculation > in RTL loop optimizations. > > Should we mark it as such? > > It is not an optimization strictly speaking. It is a better register pressure calculation used for invariant loop motion decisions. On the other hand, using this option can improve generated code performance (e.g. as I remember it improved SPECFP2000 by 1% for ppc64). So I guess, it should mark as such in order to see this possibility to improve the code by a programmer.
ira-loop-pressure not marked as optimization?
Hi, Upon noticing ira-hoist-pressure in `gcc --help=optimizers` and not ira-loop-pressure, I am wondering why the latter is not marked as an Optimization in common.opt: fira-loop-pressure Common Report Var(flag_ira_loop_pressure) Use IRA based register pressure calculation in RTL loop optimizations. Should we mark it as such? Cheers, Paulo Matos
Please have a look at PR60438
Hi, I have found a crash when compiling,and have narrowed the bug scope in the csa pass.But I am not quite familar with that.Please help. Cause: if (hasRelativeWidth || hasRelativeHeight) true false / \ /\ / \ ...... call availableWidth() call size() this function returns a structure,which matches "call_pop" .cfa_offset 96 .cfa_offset 92 \ push edx (should has a REG_ARGS_SIZE 16 here, \ but csa eliminates it) \(inlined functions are expanded here) \ / \ / \ / (should all be cfa_offset 96) add 16,%esp As the cfg above described,both branches should be end with cfa offset 96,but one branch is end with 92. That will case assertion failure in dwarf2cfi.c:2339,which asserts that all the branches should have the same cfa offset when coming to the joint. -- Regards lin zuojian
Re: asking your advice about bug
On 02/17/2014 06:50 PM, Roman Gareev wrote:
Hi Tobias,
thanks for the answer!
I think that the segfault is being caused by NULL arguments being passedto
compute_deps
by loop_level_carries_dependences.*This is **causing **an* *assignment of**
NULL values to the following parameters of **compute_deps:* must_raw_no_source,
may_raw_no_source, must_war_no_source, may_war_no_source,
must_waw_no_source, may_waw_no_source. They are being passed to
subtract_commutative_associative_deps
and dereferenced in the following statements:
*must_raw_no_source = isl_union_map_subtract (*must_raw_no_source,
x_must_raw_no_source);
*may_raw_no_source = isl_union_map_subtract (*may_raw_no_source,
x_may_raw_no_source);
*must_war_no_source = isl_union_map_subtract (*must_war_no_source,
x_must_war_no_source);
*may_war_no_source = isl_union_map_subtract (*may_war_no_source,
x_may_war_no_source);
*must_waw_no_source = isl_union_map_subtract (*must_waw_no_source,
x_must_waw_no_source);
*may_waw_no_source = isl_union_map_subtract (*may_waw_no_source,
x_may_waw_no_source);
This is the reason of segfault. (All functions mentioned above are located
in gcc/graphite-dependences.c)
I think that this can be solved by the addition to
subtract_commutative_associative_deps of NULL checking of the following
variables: must_raw_no_source, may_raw_no_source, must_war_no_source,
may_war_no_source, must_waw_no_source, may_waw_no_source. I've implemented
this in the patch, which can be found below.
Tested x86_64-unknown-linux-gnu, applying to revisions 189156, 207802
(svn://gcc.gnu.org/svn/gcc/trunk) and 207802
(svn://gcc.gnu.org/svn/gcc/branches/ibm/gcc-4_8-branch)
Thanks for your answers and advice, Sven!
--
Roman Gareev
-- --- You received this message because you are subscribed to the
Google Groups "GCC GRAPHITE" group. To unsubscribe from this group and
stop receiving emails from it, send an email to
gcc-graphite+unsubscr...@googlegroups.com. For more options, visit
https://groups.google.com/groups/opt_out.
patch
diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index b0f8680..002e3d1 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -424,24 +424,83 @@ subtract_commutative_associative_deps (scop_p scop,
&x_may_waw_no_source);
gcc_assert (res == 0);
- *must_raw = isl_union_map_subtract (*must_raw, x_must_raw);
- *may_raw = isl_union_map_subtract (*may_raw, x_may_raw);
- *must_raw_no_source = isl_union_map_subtract (*must_raw_no_source,
- x_must_raw_no_source);
- *may_raw_no_source = isl_union_map_subtract (*may_raw_no_source,
-x_may_raw_no_source);
- *must_war = isl_union_map_subtract (*must_war, x_must_war);
- *may_war = isl_union_map_subtract (*may_war, x_may_war);
- *must_war_no_source = isl_union_map_subtract (*must_war_no_source,
- x_must_war_no_source);
- *may_war_no_source = isl_union_map_subtract (*may_war_no_source,
-x_may_war_no_source);
- *must_waw = isl_union_map_subtract (*must_waw, x_must_waw);
- *may_waw = isl_union_map_subtract (*may_waw, x_may_waw);
- *must_waw_no_source = isl_union_map_subtract (*must_waw_no_source,
- x_must_waw_no_source);
- *may_waw_no_source = isl_union_map_subtract (*may_waw_no_source,
-x_may_waw_no_source);
+ if (must_raw)
+ *must_raw = isl_union_map_subtract (*must_raw, x_must_raw);
+ else
+ isl_union_map_free (x_must_raw);
+
+ if (may_raw)
+ *may_raw = isl_union_map_subtract (*may_raw, x_may_raw);
+ else
+ isl_union_map_free (x_may_raw);
In my understanding, it is sufficient to guard the no_source statements, no?
+
+ if (must_raw_no_source)
+ {
+ *must_raw_no_source = isl_union_map_subtract (*must_raw_no_source,
+ x_must_raw_no_source);
+ }
+ else
+ isl_union_map_free (x_must_raw_no_source);
Could you remove the '{' '}' around the first statement?
+
+ if (may_raw_no_source)
+ {
+ *may_raw_no_source = isl_union_map_subtract (*may_raw_no_source,
+x_may_raw_no_source);
+ }
+ else
+ isl_union_map_free (x_may_raw_no_source);
Could you remove the '{' '}' around the first statement?
+ if (must_war)
+ *must_war = isl_union_map_subtract (*must_war, x_must_war);
+ else
+ isl_union_map_free (x_must_war);
+
+ if (may_war)
+ *may_war = isl_union_map_subtract (*may_war, x_may_w
Re: asking your advice about bug
On 03/02/2014 08:06 PM, Roman Gareev wrote: Yes, this would be a 'solution'. However, I am in fact surprised that those variables are NULL at all. Do you have an idea why this is the case? Understanding this would help to understand if the patch you propose is actually the right solution or if it is just hiding a previous bug. Hi Tobias, After consideration of almost all the code in gcc/graphite-dependences.c, I think that the NULL arguments being passed to compute_deps are appropriate for loop_level_carries_dependences. I slowly come to the same conclusion. Thanks a lot for digging deeper into this. In my opinion, loop_level_carries_dependences uses the following algorithm to determine if the loop at the level DEPTH carries dependences: This function uses compute_deps for finding RAW, WAR and WAW dependences of all basic blocks in the body of the given loop. Subsequently, it tries to determine presence of these dependences at the given level. I think that it tries to find loop-independent dependences [1] in carries_deps. Therefore it maps the relation of dependences to the relation of the corresponding time-stamps and intersects the result with the relation in which all the inputs before DEPTH occur at the same time as the output, and the input at DEPTH occurs before output. Yes, it checks if all dependences are carried by outer loops already. If the intersection is not empty, some dependences are carried by the DEPTH we currently check and the loop is consequently not parallel. > I might be wrong, but I suppose that no_source dependences are *unnecessary* for this algorithm. Yes, this analysis is very correct. In that light, I believe your previous patch is correct. I will review it and we can probably commit it. Thanks for working on this! Tobias
Re: [gsoc 2014] moving fold-const patterns to gimple
On Mon, Mar 3, 2014 at 3:32 PM, Richard Biener
wrote:
> On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni
> wrote:
>> Hi, I am an undergraduate student at University of Pune, India, and would
>> like to work on moving folding patterns from fold-const.c to gimple.
>
> I've seen the entry on our GSoC project page and edited it to discourage
> people from working on that line. See
>
> http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
>
> for why. I think that open-coding the transforms isn't maintainable
> in the long run.
>
>> If I understand correctly, constant folding is done on GENERIC (by
>> routines in fold-const.c), and then GENERIC is lowered to GIMPLE. The
>> purpose of this project,
>> is to have constant folding to be performed on GIMPLE instead (in
>> gimple-fold.c?)
>>
>> I have a few elementary questions to ask:
>>
>> a) A contrived example:
>> Consider a C expression, a = ~0 (assume a is int)
>> In GENERIC, this would roughly be represented as:
>> modify_expr>>
>> this gets folded to:
>> modify_expr
>> and the corresponding gimple tuple generated is (-fdump-tree-gimple-raw):
>> gimple_assign
>>
>> So, instead of folding performed on GENERIC, it should be
>> done on GIMPLE.
>> So a tuple like the following should be generated by gimplification:
>>
>> and folded to (by call to fold_stmt):
>>
>> Is this the expected behavior ?
>>
>> I have attached a rough/incomplete patch (only stage1 compiled cc1), that
>> does the following foldings on bit_not_expr:
>> a) ~ INTEGER_CST => folded
>> b) ~~x => x
>> c) ~(-x) => x - 1
>> (For the moment, I put case BIT_NOT_EXPR: return NULL_TREE
>> in fold_unary_loc to avoid folding in GENERIC on bit_not_expr)
>>
>> Is the patch going in the correct direction ? Or have I completely missed
>> the point here ? I would be grateful to receive suggestions, and start
>> working
>> on a fair patch.
>
> I think you implement what was suggested by Kai (and previously
> by me and Andrew, before I changed my mind).
>
Hi Richard,
Thanks for your reply and for pointing me out to this thread
http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html
I agree it's better to generate patterns from a meta-description
instead of hand-coding, and the idea seems interesting to me.
I was playing around with the patch and did few trivial modifications
(please find the patch attached):
a) use obstack in parse_c_expr.
b) use @ inside c code, instead of directly writing captures
(like $ in bison):
example:
/* Match and simplify CST + CST to CST'. */
(define_match_and_simplify baz
(PLUS_EXPR INTEGER_CST_P@0 INTEGER_CST_P@1)
{ int_const_binop (PLUS_EXPR, @0, @1); })
c) Not sure if this is a good idea, conditional matching.
for example:
/* match (A * B) and simplify to
* B if integer_zerop B is true ( A * 0 => 0)
* A if integer_onep B is true (A * 1 => A)
*/
(define_match_and_simplify multexpr
(MULT_EXPR integral_op_p@0 integral_op_p@1)
[
(integer_zerop@1 @1)
(integer_onep@1 @0)
])
Maybe condition can be generalized to be any operand instead of
testing predicate on capture operand ?
I would be grateful to receive some direction for working on this project.
>From the thread, I see a few possibilities:
a) Moving patterns from tree-ssa-forwprop
b) Extending the DSL (handle commutative operators, conditionally
enabling patterns ?)
c) Targeting GENERIC (Generating patterns in fold-const.c from the
description ?)
d) This is a bit silly, but maybe perform more error checking ?
for example the following pattern is currently accepted:
(define_match px
(PLUS_EXPR @0 @1 @2))
I wanted to apply to gsoc for this project and I was wondering if you
would you be willing to mentor me if I did?
I have a fluent grasp on C and working knowledge of flex, bison, C++,
POSIX api, binutils and shell scripting (bash),
I have been through most of dragon book, built an interpreter
for a "c-like" language and a C-code generator for a toy language
similar to python.
As far as gcc goes, I had attended IIT Bombay gcc workshop 2013:
http://www.cse.iitb.ac.in/grc/gcc-workshop-13/
and have been through the online docs.
I have a couple of one-liner patches committed:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00490.html
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01144.html
A few pending patches:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00143.html
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00143.html
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01220.html
http://gcc.gnu.org/ml/gcc/2014-01/msg00268.html
and a couple of rejected ones:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00957.html
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01366.html
Please do let me know what you think.
Thanks and Regards,
Prathamesh
> Richard.
>
>> On the following test-case:
>> int main()
>> {
>> int a, b, c;
>> a = b;
>> c = ~-a;
>> return 0;
>> }
>>
>> The following GIMPLE is generated:
>> main ()
>> gimple_bind <
>> int D.1748;
>> int D.1749;
>> int D.1750;
>> int D.1751;
>> int D.
Re: Can Some one please help me on this gcc plugin..
Hi David,
I am very much thankful to you as your answer worked wonders for me.
The problem with the plugin is solved now. Thanks again.
On 3/5/14, David Malcolm wrote:
> On Wed, 2014-03-05 at 21:58 +0530, Mohsin Khan wrote:
>> Hi,
>>
>> I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
>> I wrote a plugin and tried to count and see the Goto Statements using
>> the gimple_stmt_iterator. I get gimple statements printed on my
>> stdout, but I am not able to find the line which has goto statements.
>> I only get other lines such as variable declaration and logic
>> statements, but no goto statements.
>> When I open the Gimple/SSA/CFG file seperately using the vim editor
>> I find the goto statements are actually present.
>> So, can anyone help me. How can I actually get the count of Goto
>> statements or atleast access these goto statements using some
>> iterator.
>> I have used -fdump-tree-all, -fdump-tree-cfg as flags.
>>
>> Here is the pseudocode:
>>
>> struct register_pass_info pass_info = {
>> &(pass_plugin.pass), /* Address of new pass,
>> here, the 'struct
>> opt_pass' field of
>> 'gimple_opt_pass'
>> defined above */
>> "ssa", /* Name of the reference
>> pass for hooking up
>> the new pass. ??? */
>> 0, /* Insert the pass at the
>> specified instance
>> number of the reference
>> pass. Do it for
>> every instance if it is 0.
>> */
>> PASS_POS_INSERT_AFTER/* how to insert the new
>> pass: before,
>
> You're inserting your pass after the "ssa" pass, which converts the CFG
> to SSA form. This is run *after* the function has been converted from a
> flat list of gimple statements into a CFG of basic blocks, and that CFG
> conversion eliminates the goto statements in favor of edges within the
> CFG. If you see "goto" in the dump, that's presumably just a textual
> way of expressing an edge in the CFG.
>
> To see gimple goto statements, you need to run your pass *before* the
> convertion to CFG, which happens fairly early on, in the "cfg" pass
>
> FWIW there's a diagram showing the passes here:
> http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
>
>
> Hope this is helpful
> Dave
>
>
Regards
Mohsin Khan
