This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update optimization_default_node in ada (PR middle-end/64340)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]