This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Update optimization_default_node in ada (PR middle-end/64340)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>,Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org,Richard Biener <rguenther at suse dot de>,Jan Hubicka <hubicka at ucw dot cz>
- Date: Sat, 07 Feb 2015 15:39:20 +0100
- Subject: Re: [PATCH] Update optimization_default_node in ada (PR middle-end/64340)
- Authentication-results: sourceware.org; auth=none
- References: <20150206202629 dot GP1746 at tucnak dot redhat dot com> <87406362-C829-43B8-9A2B-36FFC292B7A1 at suse dot de> <20150207103700 dot GT1746 at tucnak dot redhat dot com> <9430863 dot mcty7axLX0 at polaris>
On February 7, 2015 11:55:23 AM CET, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> I think for using option processing langhooks it would require
>massive Ada
>> FE surgery, the thing is that right now all the option processing is
>> performed, then at some later point the TU is parsed, then depending
>on what
>> is seen in there the options are tweaked and finally everything is
>handed
>> over to the middle-end. So, to do this in the option processing
>langhooks,
>> the parsing (which presumably depends on the user options etc.) would
>need
>> to be performed during the option processing.
>>
>> As for the other option, sure, instead of recreating
>> optimization_{default,current}_node as done in the patch, it could
>create
>> a different OPTIMIZATION_NODE instead, and attach it to all
>functions.
>> What would be optimization_default_node good for it isn't used for
>anything
>> though? And, the thing I'm worried about in that case is how to
>ensure the
>> ada_optimization_default_node or how would it be called optimization
>node is
>> used even on all compiler generated functions, not just user
>functions.
>>
>> So, from this POV my patch sounds like the simplest solution, both
>the above
>> options would be IMHO significantly more work. If some Ada
>maintainer is
>> willing to do that, sure, no problem with that, but I know next to
>nothing
>> about Ada and thus I'm afraid what I've posted is all I can offer for
>this
>> PR.
>
>I don't think that the langhook approach is realistically doable,
>unless of
>course you want to add a new dedicated langhook. The Ada compiler
>needs to
>adjust the behavior of the middle-end and the optimizers after parsing
>the
>compilation unit and this cannot really be changed.
>
>The second approach is more appealing but I'll defer to your judgement
>here
>because you know this stuff much better than me.
>
>To sum up, if you think that the patch is a plausible kludge, then go
>ahead.
OK with me as well then.
Richard.