* [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
@ 2012-07-11 5:21 Sandeep Soni
2012-07-17 7:52 ` Bernhard Reutner-Fischer
2012-08-02 17:12 ` Diego Novillo
0 siblings, 2 replies; 6+ messages in thread
From: Sandeep Soni @ 2012-07-11 5:21 UTC (permalink / raw)
To: gcc patches; +Cc: Diego Novillo
The patch adds support for creating individual gimple statements for
the gimple_cond and gimple_label statements.
Diego, I need your help in generalizing to include all possible cases
of these statements.
Here is the ChangeLog
2012-07-10 Sandeep Soni <soni.sandeepb@gmail.com>
* parser.c (gp_parse_expect_op1): Tidy. Returns tree operand.
Update all callers.
(gp_parse_expect_op2): Likewise.
(gp_parse_expect_true_label): Tidy. Returns a label.
Update all callers.
(gp_parse_expect_false_label): Likewise.
(gp_parse_cond_stmt): Tidy. Creates and returns a gimple cond
statement.
(gp_parse_label_stmt): Creates and returns the gimple label statement.
And the patch
Index: gcc/gimple/parser.c
===================================================================
--- gcc/gimple/parser.c (revision 188546)
+++ gcc/gimple/parser.c (working copy)
-static void
+static tree
gp_parse_expect_op1 (gimple_parser *parser)
{
const gimple_token *next_token;
next_token = gl_consume_token (parser->lexer);
+ tree op1 = NULL_TREE;
switch (next_token->type)
{
case CPP_NAME:
+ op1 = gimple_symtab_get_token (next_token);
+ break;
+
case CPP_NUMBER:
break;
@@ -476,20 +529,24 @@
}
gl_consume_expected_token (parser->lexer, CPP_COMMA);
+ return op1;
}
/* Helper for gp_parse_cond_stmt. The token read from reader PARSER should
be the second operand in the tuple. */
-static void
+static tree
gp_parse_expect_op2 (gimple_parser *parser)
{
const gimple_token *next_token;
next_token = gl_consume_token (parser->lexer);
-
+ tree op2 = NULL_TREE;
switch (next_token->type)
{
case CPP_NAME:
+ op2 = gimple_symtab_get_token (next_token);
+ break;
+
case CPP_NUMBER:
case CPP_STRING:
break;
@@ -503,50 +560,55 @@
break;
}
- gl_consume_expected_token (parser->lexer, CPP_COMMA);
+ gl_consume_expected_token (parser->lexer, CPP_COMMA);
+ return op2;
}
/* Helper for gp_parse_cond_stmt. The token read from reader PARSER should
be the true label in the tuple that means the label where the control
jumps if the condition evaluates to true. */
-static void
+static tree
gp_parse_expect_true_label (gimple_parser *parser)
{
gl_consume_expected_token (parser->lexer, CPP_LESS);
gl_consume_expected_token (parser->lexer, CPP_NAME);
gl_consume_expected_token (parser->lexer, CPP_GREATER);
gl_consume_expected_token (parser->lexer, CPP_COMMA);
+ return create_artificial_label (UNKNOWN_LOCATION);
}
/* Helper for gp_parse_cond_stmt. The token read from reader PARSER should
be the false label in the tuple that means the label where the control
jumps if the condition evaluates to false. */
-static void
+static tree
gp_parse_expect_false_label (gimple_parser *parser)
{
gl_consume_expected_token (parser->lexer, CPP_LESS);
gl_consume_expected_token (parser->lexer, CPP_NAME);
gl_consume_expected_token (parser->lexer, CPP_GREATER);
gl_consume_expected_token (parser->lexer, CPP_GREATER);
+ return create_artificial_label (UNKNOWN_LOCATION);
}
/* Parse a gimple_cond tuple that is read from the reader PARSER. For
now we only recognize the tuple. Refer gimple.def for the format of
this tuple. */
-static void
+static gimple
gp_parse_cond_stmt (gimple_parser *parser)
{
gimple_token *optoken;
enum tree_code opcode = gp_parse_expect_subcode (parser, &optoken);
if (get_gimple_rhs_class (opcode) != GIMPLE_BINARY_RHS)
error_at (optoken->location, "Unsupported gimple_cond expression");
- gp_parse_expect_op1 (parser);
- gp_parse_expect_op2 (parser);
- gp_parse_expect_true_label (parser);
- gp_parse_expect_false_label (parser);
+ tree op1 = gp_parse_expect_op1 (parser);
+ tree op2 = gp_parse_expect_op2 (parser);
+ tree true_label = gp_parse_expect_true_label (parser);
+ tree false_label = gp_parse_expect_false_label (parser);
+ gimple cond_stmt = gimple_build_cond (opcode, op1, op2, true_label,
false_label);
+ return cond_stmt;
}
/* Parse a gimple_goto tuple that is read from the reader PARSER. For
@@ -567,14 +629,18 @@
now we only recognize the tuple. Refer gimple.def for the format of
this tuple. */
-static void
+static gimple
gp_parse_label_stmt (gimple_parser *parser)
{
gl_consume_expected_token (parser->lexer, CPP_LESS);
gl_consume_expected_token (parser->lexer, CPP_LESS);
- gl_consume_expected_token (parser->lexer, CPP_NAME);
+ gimple_token *token = gl_consume_token (parser->lexer);
gl_consume_expected_token (parser->lexer, CPP_GREATER);
- gl_consume_expected_token (parser->lexer, CPP_GREATER);
+ gl_consume_expected_token (parser->lexer, CPP_GREATER);
+
+ tree label = create_artificial_label (token->location);
+ gimple stmt = gimple_build_label (label);
+ return stmt;
}
/* Parse a gimple_switch tuple that is read from the reader PARSER.
--
Cheers
Sandy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
2012-07-11 5:21 [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label Sandeep Soni
@ 2012-07-17 7:52 ` Bernhard Reutner-Fischer
2012-07-17 9:01 ` Sandeep Soni
2012-08-02 17:12 ` Diego Novillo
1 sibling, 1 reply; 6+ messages in thread
From: Bernhard Reutner-Fischer @ 2012-07-17 7:52 UTC (permalink / raw)
To: Sandeep Soni; +Cc: gcc patches, Diego Novillo
On Wed, Jul 11, 2012 at 10:51:02AM +0530, Sandeep Soni wrote:
>The patch adds support for creating individual gimple statements for
>the gimple_cond and gimple_label statements.
>
>Diego, I need your help in generalizing to include all possible cases
>of these statements.
>
>Here is the ChangeLog
>
>2012-07-10 Sandeep Soni <soni.sandeepb@gmail.com>
>
> * parser.c (gp_parse_expect_op1): Tidy. Returns tree operand.
> Update all callers.
> (gp_parse_expect_op2): Likewise.
> (gp_parse_expect_true_label): Tidy. Returns a label.
> Update all callers.
> (gp_parse_expect_false_label): Likewise.
> (gp_parse_cond_stmt): Tidy. Creates and returns a gimple cond
> statement.
> (gp_parse_label_stmt): Creates and returns the gimple label statement.
>
>
>And the patch
>Index: gcc/gimple/parser.c
>===================================================================
>--- gcc/gimple/parser.c (revision 188546)
>+++ gcc/gimple/parser.c (working copy)
>
>-static void
>+static tree
> gp_parse_expect_op1 (gimple_parser *parser)
> {
> const gimple_token *next_token;
> next_token = gl_consume_token (parser->lexer);
>+ tree op1 = NULL_TREE;
I'm curious if the coding conventions were relaxed to allow for variable
declarations that are not at the beginning of a function or scope?
You seem to do this pretty often in the gimplefe..
cheers,
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
2012-07-17 7:52 ` Bernhard Reutner-Fischer
@ 2012-07-17 9:01 ` Sandeep Soni
2012-07-17 12:46 ` Diego Novillo
0 siblings, 1 reply; 6+ messages in thread
From: Sandeep Soni @ 2012-07-17 9:01 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: gcc patches, Diego Novillo
On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
>
> I'm curious if the coding conventions were relaxed to allow for variable
> declarations that are not at the beginning of a function or scope?
>
> You seem to do this pretty often in the gimplefe..
>
> cheers,
Not really. I guess, I am the one at fault for this. I will ensure the
existing code is fixed so that the conventions are followed. Thanks
for pointing it out.
--
Cheers
Sandy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
2012-07-17 9:01 ` Sandeep Soni
@ 2012-07-17 12:46 ` Diego Novillo
2012-07-18 6:51 ` Sandeep Soni
0 siblings, 1 reply; 6+ messages in thread
From: Diego Novillo @ 2012-07-17 12:46 UTC (permalink / raw)
To: Sandeep Soni; +Cc: Bernhard Reutner-Fischer, gcc patches
On Tue, Jul 17, 2012 at 11:01 AM, Sandeep Soni <soni.sandeepb@gmail.com> wrote:
> On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer
> <rep.dot.nop@gmail.com> wrote:
>>
>> I'm curious if the coding conventions were relaxed to allow for variable
>> declarations that are not at the beginning of a function or scope?
>>
>> You seem to do this pretty often in the gimplefe..
>>
>> cheers,
>
> Not really. I guess, I am the one at fault for this. I will ensure the
> existing code is fixed so that the conventions are followed. Thanks
> for pointing it out.
Not so much, anymore
(http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe
is merged into trunk, we will be using the C++ conventions which now
allow this.
No need to change anything, Sandy.
Diego.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
2012-07-17 12:46 ` Diego Novillo
@ 2012-07-18 6:51 ` Sandeep Soni
0 siblings, 0 replies; 6+ messages in thread
From: Sandeep Soni @ 2012-07-18 6:51 UTC (permalink / raw)
To: Diego Novillo; +Cc: Bernhard Reutner-Fischer, gcc patches
On Tue, Jul 17, 2012 at 6:16 PM, Diego Novillo <dnovillo@google.com> wrote:
>
> Not so much, anymore
> (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe
> is merged into trunk, we will be using the C++ conventions which now
> allow this.
>
> No need to change anything, Sandy.
Ah..Saved by the skin of my teeth. Thanks!
--
Cheers
Sandy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
2012-07-11 5:21 [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label Sandeep Soni
2012-07-17 7:52 ` Bernhard Reutner-Fischer
@ 2012-08-02 17:12 ` Diego Novillo
1 sibling, 0 replies; 6+ messages in thread
From: Diego Novillo @ 2012-08-02 17:12 UTC (permalink / raw)
To: Sandeep Soni; +Cc: gcc patches
On Tue, Jul 10, 2012 at 10:21 PM, Sandeep Soni <soni.sandeepb@gmail.com> wrote:
> -static void
> +static tree
> gp_parse_expect_false_label (gimple_parser *parser)
> {
> gl_consume_expected_token (parser->lexer, CPP_LESS);
> gl_consume_expected_token (parser->lexer, CPP_NAME);
> gl_consume_expected_token (parser->lexer, CPP_GREATER);
> gl_consume_expected_token (parser->lexer, CPP_GREATER);
> + return create_artificial_label (UNKNOWN_LOCATION);
You don't need to use UNKNOWN_LOCATION here. You can use the location
from gl_peek_token(parser->lexer)->location.
OK with that change.
Diego.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-08-02 17:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-11 5:21 [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label Sandeep Soni
2012-07-17 7:52 ` Bernhard Reutner-Fischer
2012-07-17 9:01 ` Sandeep Soni
2012-07-17 12:46 ` Diego Novillo
2012-07-18 6:51 ` Sandeep Soni
2012-08-02 17:12 ` Diego Novillo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).