This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [GIMPLE FE] Handle abs_expr
- From: Richard Biener <rguenther at suse dot de>
- To: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- Cc: gcc Patches <gcc-patches at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 7 Feb 2017 15:36:47 +0100 (CET)
- Subject: Re: [GIMPLE FE] Handle abs_expr
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjMnmmAZ1=PkPnTpt1PHtX5WiXongK=PoMKK7aFMXTcjvHQ@mail.gmail.com>
On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
> Hi Richard,
> The attached patch tries to handle ABS_EXPR in gimple-fe.
> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
> or parse it as keyword (like __GIMPLE). Currently in the patch, I
> parse it as id.
> Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
Few comments - the new oper_code argument to unary parsing seems
superfluous - you check the name again for __ABS_EXPR. Also I'd
spell it __ABS, without the _EXPR part.
For __MEM we go to binary op parsing and then take the "not binary op"
route. I guess some refactoring might clean up things here - not for
now though.
I'm not sure whether new RID_ keywords would be prefered for this
kind of stuff. We added one for __PHI. Joseph, is the RID_ space
somehow limited so that we should avoid ending up with, say, up to
226 RID_s for GIMPLE (upper estimate taken from the number of
tree codes we have in tree.def)? I see currently cpplib puts
rid_code into an unsigned char and we do already seem to have quite
some of them (114 if I count correctly).
Thanks,
Richard.