On February 7, 2015 11:55:23 AM CET, Eric Botcazou <ebotca...@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.
