Re: [gimplefe] Parsing __GIMPLE function body
On 30 May 2016 at 20:45, Prasad Ghangal wrote:
> Hi,
>
> As David suggested in his rtlfe patch,
> this patch recognizes __GIMPLE keyword and switches to
> c_parser_parse_gimple_body by providing -fgimple option.
>
>
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 4568cf6..41a8f05 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>{ "__volatile",RID_VOLATILE,0 },
>{ "__volatile__",RID_VOLATILE,0 },
> + { "__GIMPLE",RID_GIMPLE,0 },
>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>{ "asm",RID_ASM,D_ASM },
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index 0295532..23a401d 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -104,6 +104,9 @@ enum rid
>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>
> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
> + RID_GIMPLE,
> +
>/* C11 */
>RID_ALIGNAS, RID_GENERIC,
>
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 918df16..8ab56af 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -200,6 +200,10 @@ F
> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
> after %qs)
> -F Add to the end of the main framework include path.
>
> +fgimple
> +C Var(flag_gimple) Init(0)
> +Enable parsing GIMPLE
> +
> H
> C ObjC C++ ObjC++
> Print the name of header files as they are used.
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 1cf4fb4..c5a4d3f 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
> *, enum pragma_context);
> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
> static void c_parser_cilk_grainsize (c_parser *, bool *);
> +static void c_parser_parse_gimple_body (c_parser *parser);
>
> /* Parse a translation unit (C90 6.7, C99 6.9).
>
> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
> bool fndef_ok,
>tree all_prefix_attrs;
>bool diagnosed_no_specs = false;
>location_t here = c_parser_peek_token (parser)->location;
> + bool gimple_body_p = false;
>
>if (static_assert_ok
>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
>c_parser_skip_to_end_of_block_or_statement (parser);
>return;
> }
> +
> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
> +{
> + c_token *kw_token = c_parser_peek_token (parser);
> + if (kw_token->keyword == RID_GIMPLE)
> +{
> + gimple_body_p = true;
> + c_parser_consume_token (parser);
> +}
> +}
> +
>finish_declspecs (specs);
>bool auto_type_p = specs->typespec_word == cts_auto_type;
>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
> oacc_routine_clauses, false, first, true);
>DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
> = c_parser_peek_token (parser)->location;
> +
> + if (gimple_body_p && flag_gimple)
> +{
> + c_parser_parse_gimple_body (parser);
> + finish_function ();
> + return;
> +}
> +
>fnbody = c_parser_compound_statement (parser);
>if (flag_cilkplus && contains_array_notation_expr (fnbody))
> fnbody = expand_array_notation_exprs (fnbody);
> @@ -2123,7 +2144,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
> bool fndef_ok,
>add_stmt (fnbody);
>finish_function ();
> }
> -
> +
>timevar_pop (tv);
>break;
> }
> @@ -18055,4 +18076,23 @@ c_parser_array_notation (location_t loc,
> c_parser *parser, tree initial_index,
>return value_tree;
> }
>
> +/* Parse the body of a function declaration marked with "__GIMPLE". */
> +
> +void
> +c_parser_parse_gimple_body (c_parser *parser)
> +{
> + if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
> +return;
> +
> + location_t loc1 = c_parser_peek_token (parser)->location;
> + inform (loc1, "start of GIMPLE");
> +
> + while (c_parser_next_token_is_not (parser, CPP_CLOSE_BRACE))
Could this possibly go into infinite loop if '}' is not present in the source ?
Thanks,
Prathamesh
> +{
> +c_parser_consume_token (parser);
> +}
> +
> + c_parser_consume_token (parser);
> +}
> +
> #include "gt-c-c-parser.h"
>
>
>
>
> GIMPLE function body consists of GIMPLE statements. For parsing GIMPLE
> f
Re: [gimplefe] Parsing __GIMPLE function body
On Wed, Jun 1, 2016 at 9:19 AM, Prathamesh Kulkarni
wrote:
> On 30 May 2016 at 20:45, Prasad Ghangal wrote:
>> Hi,
>>
>> As David suggested in his rtlfe patch,
>> this patch recognizes __GIMPLE keyword and switches to
>> c_parser_parse_gimple_body by providing -fgimple option.
>>
>>
>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>> index 4568cf6..41a8f05 100644
>> --- a/gcc/c-family/c-common.c
>> +++ b/gcc/c-family/c-common.c
>> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>>{ "__volatile",RID_VOLATILE,0 },
>>{ "__volatile__",RID_VOLATILE,0 },
>> + { "__GIMPLE",RID_GIMPLE,0 },
>>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>{ "asm",RID_ASM,D_ASM },
>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>> index 0295532..23a401d 100644
>> --- a/gcc/c-family/c-common.h
>> +++ b/gcc/c-family/c-common.h
>> @@ -104,6 +104,9 @@ enum rid
>>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>>
>> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
>> + RID_GIMPLE,
>> +
>>/* C11 */
>>RID_ALIGNAS, RID_GENERIC,
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 918df16..8ab56af 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -200,6 +200,10 @@ F
>> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
>> after %qs)
>> -F Add to the end of the main framework include path.
>>
>> +fgimple
>> +C Var(flag_gimple) Init(0)
>> +Enable parsing GIMPLE
>> +
>> H
>> C ObjC C++ ObjC++
>> Print the name of header files as they are used.
>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>> index 1cf4fb4..c5a4d3f 100644
>> --- a/gcc/c/c-parser.c
>> +++ b/gcc/c/c-parser.c
>> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
>> *, enum pragma_context);
>> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
>> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
>> static void c_parser_cilk_grainsize (c_parser *, bool *);
>> +static void c_parser_parse_gimple_body (c_parser *parser);
>>
>> /* Parse a translation unit (C90 6.7, C99 6.9).
>>
>> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>> bool fndef_ok,
>>tree all_prefix_attrs;
>>bool diagnosed_no_specs = false;
>>location_t here = c_parser_peek_token (parser)->location;
>> + bool gimple_body_p = false;
>>
>>if (static_assert_ok
>>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
>> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
>> *parser, bool fndef_ok,
>>c_parser_skip_to_end_of_block_or_statement (parser);
>>return;
>> }
>> +
>> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
>> +{
>> + c_token *kw_token = c_parser_peek_token (parser);
>> + if (kw_token->keyword == RID_GIMPLE)
>> +{
>> + gimple_body_p = true;
>> + c_parser_consume_token (parser);
>> +}
>> +}
>> +
>>finish_declspecs (specs);
>>bool auto_type_p = specs->typespec_word == cts_auto_type;
>>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
>> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
>> *parser, bool fndef_ok,
>> oacc_routine_clauses, false, first, true);
>>DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
>> = c_parser_peek_token (parser)->location;
>> +
>> + if (gimple_body_p && flag_gimple)
>> +{
>> + c_parser_parse_gimple_body (parser);
>> + finish_function ();
>> + return;
>> +}
>> +
>>fnbody = c_parser_compound_statement (parser);
>>if (flag_cilkplus && contains_array_notation_expr (fnbody))
>> fnbody = expand_array_notation_exprs (fnbody);
>> @@ -2123,7 +2144,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>> bool fndef_ok,
>>add_stmt (fnbody);
>>finish_function ();
>> }
>> -
>> +
>>timevar_pop (tv);
>>break;
>> }
>> @@ -18055,4 +18076,23 @@ c_parser_array_notation (location_t loc,
>> c_parser *parser, tree initial_index,
>>return value_tree;
>> }
>>
>> +/* Parse the body of a function declaration marked with "__GIMPLE". */
>> +
>> +void
>> +c_parser_parse_gimple_body (c_parser *parser)
>> +{
>> + if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
>> +return;
>> +
>> + location_t loc1 = c_parser_peek_token (parser)->location;
>> + inform (loc1, "start of GIMPLE");
>> +
>> + while (c_parser_next_token_is_not (parser, CPP_CLOSE_BRACE))
> Could this possibly go into infinite loop if '}' is not present in the source
> ?
You'd have to look into the source but I g
Re: [gimplefe] Parsing __GIMPLE function body
On 1 June 2016 at 15:19, Richard Biener wrote:
> On Wed, Jun 1, 2016 at 9:19 AM, Prathamesh Kulkarni
> wrote:
>> On 30 May 2016 at 20:45, Prasad Ghangal wrote:
>>> Hi,
>>>
>>> As David suggested in his rtlfe patch,
>>> this patch recognizes __GIMPLE keyword and switches to
>>> c_parser_parse_gimple_body by providing -fgimple option.
>>>
>>>
>>> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
>>> index 4568cf6..41a8f05 100644
>>> --- a/gcc/c-family/c-common.c
>>> +++ b/gcc/c-family/c-common.c
>>> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>>>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>>>{ "__volatile",RID_VOLATILE,0 },
>>>{ "__volatile__",RID_VOLATILE,0 },
>>> + { "__GIMPLE",RID_GIMPLE,0 },
>>>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>>>{ "asm",RID_ASM,D_ASM },
>>> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
>>> index 0295532..23a401d 100644
>>> --- a/gcc/c-family/c-common.h
>>> +++ b/gcc/c-family/c-common.h
>>> @@ -104,6 +104,9 @@ enum rid
>>>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>>>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>>>
>>> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
>>> + RID_GIMPLE,
>>> +
>>>/* C11 */
>>>RID_ALIGNAS, RID_GENERIC,
>>>
>>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>>> index 918df16..8ab56af 100644
>>> --- a/gcc/c-family/c.opt
>>> +++ b/gcc/c-family/c.opt
>>> @@ -200,6 +200,10 @@ F
>>> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
>>> after %qs)
>>> -F Add to the end of the main framework include path.
>>>
>>> +fgimple
>>> +C Var(flag_gimple) Init(0)
>>> +Enable parsing GIMPLE
>>> +
>>> H
>>> C ObjC C++ ObjC++
>>> Print the name of header files as they are used.
>>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>>> index 1cf4fb4..c5a4d3f 100644
>>> --- a/gcc/c/c-parser.c
>>> +++ b/gcc/c/c-parser.c
>>> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
>>> *, enum pragma_context);
>>> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
>>> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
>>> static void c_parser_cilk_grainsize (c_parser *, bool *);
>>> +static void c_parser_parse_gimple_body (c_parser *parser);
>>>
>>> /* Parse a translation unit (C90 6.7, C99 6.9).
>>>
>>> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>>> bool fndef_ok,
>>>tree all_prefix_attrs;
>>>bool diagnosed_no_specs = false;
>>>location_t here = c_parser_peek_token (parser)->location;
>>> + bool gimple_body_p = false;
>>>
>>>if (static_assert_ok
>>>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
>>> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
>>> *parser, bool fndef_ok,
>>>c_parser_skip_to_end_of_block_or_statement (parser);
>>>return;
>>> }
>>> +
>>> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
>>> +{
>>> + c_token *kw_token = c_parser_peek_token (parser);
>>> + if (kw_token->keyword == RID_GIMPLE)
>>> +{
>>> + gimple_body_p = true;
>>> + c_parser_consume_token (parser);
>>> +}
>>> +}
>>> +
>>>finish_declspecs (specs);
>>>bool auto_type_p = specs->typespec_word == cts_auto_type;
>>>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
>>> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
>>> *parser, bool fndef_ok,
>>> oacc_routine_clauses, false, first, true);
>>>DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
>>> = c_parser_peek_token (parser)->location;
>>> +
>>> + if (gimple_body_p && flag_gimple)
>>> +{
>>> + c_parser_parse_gimple_body (parser);
>>> + finish_function ();
>>> + return;
>>> +}
>>> +
>>>fnbody = c_parser_compound_statement (parser);
>>>if (flag_cilkplus && contains_array_notation_expr (fnbody))
>>> fnbody = expand_array_notation_exprs (fnbody);
>>> @@ -2123,7 +2144,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
>>> bool fndef_ok,
>>>add_stmt (fnbody);
>>>finish_function ();
>>> }
>>> -
>>> +
>>>timevar_pop (tv);
>>>break;
>>> }
>>> @@ -18055,4 +18076,23 @@ c_parser_array_notation (location_t loc,
>>> c_parser *parser, tree initial_index,
>>>return value_tree;
>>> }
>>>
>>> +/* Parse the body of a function declaration marked with "__GIMPLE". */
>>> +
>>> +void
>>> +c_parser_parse_gimple_body (c_parser *parser)
>>> +{
>>> + if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
>>> +return;
>>> +
>>> + location_t loc1 = c_parser_peek_token (parser)->location;
>>> + inform (loc1, "start of GIMPLE");
>>> +
>>> + whi
Re: [gimplefe] Parsing __GIMPLE function body
On Wed, 2016-06-01 at 12:49 +0530, Prathamesh Kulkarni wrote:
> On 30 May 2016 at 20:45, Prasad Ghangal
> wrote:
> > Hi,
> >
> > As David suggested in his rtlfe patch,
> > this patch recognizes __GIMPLE keyword and switches to
> > c_parser_parse_gimple_body by providing -fgimple option.
> >
[snip]
> >
> > +/* Parse the body of a function declaration marked with
> > "__GIMPLE". */
> > +
> > +void
> > +c_parser_parse_gimple_body (c_parser *parser)
> > +{
> > + if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected
> > %<{%>"))
> > +return;
> > +
> > + location_t loc1 = c_parser_peek_token (parser)->location;
> > + inform (loc1, "start of GIMPLE");
> > +
> > + while (c_parser_next_token_is_not (parser, CPP_CLOSE_BRACE))
> Could this possibly go into infinite loop if '}' is not present in
> the source ?
Given that right now all it does is consume the input without doing
anything with it, that's hardly a problem ;) I'm sure that as Prasad
expands this function to actually parse statements that he'll handle
this case (an explicit test case for it would be appropriate).
> Thanks,
> Prathamesh
> > +{
> > +c_parser_consume_token (parser);
> > +}
> > +
> > + c_parser_consume_token (parser);
> > +}
> > +
[snip]
gcc-4.9-20160601 is now available
Snapshot gcc-4.9-20160601 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160601/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 237020 You'll find: gcc-4.9-20160601.tar.bz2 Complete GCC MD5=9639b8951edb63b18b496a949b3e4e95 SHA1=7a55376a07b378a0e1dfe00a83efc11cb55bd9de Diffs from 4.9-20160525 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
fstrict-enums and value ranges in VRP
Hi All,
When I compile the following code with g++ using -fstrict-enums and -O2
enum v
{
OK = 0,
NOK = 1,
};
int foo0 (enum v a)
{
if (a > NOK)
return 0;
return 1;
}
vrp1 dump looks like:
Value ranges after VRP:
a.0_1: VARYING
_2: [0, 1]
a_3(D): VARYING
int foo0(v) (v a)
{
int a.0_1;
int _2;
:
a.0_1 = (int) a_3(D);
if (a.0_1 > 1)
goto ;
else
goto ;
:
:
# _2 = PHI <0(2), 1(3)>
return _2;
}
Should we infer value ranges for the enum since this is -fstrict-enums
and optimize it?
@item -fstrict-enums
@opindex fstrict-enums
Allow the compiler to optimize using the assumption that a value of
enumerated type can only be one of the values of the enumeration (as
defined in the C++ standard; basically, a value that can be
represented in the minimum number of bits needed to represent all the
enumerators). This assumption may not be valid if the program uses a
cast to convert an arbitrary integer value to the enumerated type.
Thanks,
Kugan
Re: fstrict-enums and value ranges in VRP
On Thu, Jun 02, 2016 at 08:54:36AM +1000, kugan wrote:
> Hi All,
>
> When I compile the following code with g++ using -fstrict-enums and -O2
>
> enum v
> {
> OK = 0,
> NOK = 1,
> };
>
> int foo0 (enum v a)
> {
> if (a > NOK)
> return 0;
> return 1;
> }
>
> vrp1 dump looks like:
> Value ranges after VRP:
>
> a.0_1: VARYING
> _2: [0, 1]
> a_3(D): VARYING
>
>
> int foo0(v) (v a)
> {
> int a.0_1;
> int _2;
>
> :
> a.0_1 = (int) a_3(D);
> if (a.0_1 > 1)
> goto ;
> else
> goto ;
>
> :
>
> :
> # _2 = PHI <0(2), 1(3)>
> return _2;
>
> }
>
> Should we infer value ranges for the enum since this is -fstrict-enums and
> optimize it?
>
> @item -fstrict-enums
> @opindex fstrict-enums
> Allow the compiler to optimize using the assumption that a value of
> enumerated type can only be one of the values of the enumeration (as
> defined in the C++ standard; basically, a value that can be
> represented in the minimum number of bits needed to represent all the
> enumerators). This assumption may not be valid if the program uses a
> cast to convert an arbitrary integer value to the enumerated type.
It seems like the "basically" part contradicts the first sentence?
Consider
enum Foo
{
a = 0,
b = 2
};
Foo a = (Foo) 2;
That should fit in the minimum number of bits used to represent
the enum, but clearly isn't one of the enum's constants. I
guess if vrp only says its in the range [1, 3] then it doesn't
matter.
Then consider
Foo b = (Foo) 3;
If you assume two's complement (which I believe is
implementation defined) then it also fits in the minimum number
of bits, but is clearly outside the range for vrp.
I guess given the last bit, these are both ment to be invalid?
I guess the correct thing according to the docs is to optimize,
but personally I'd be pretty scared of turning that flag on.
Trev
>
>
> Thanks,
> Kugan
