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

Eric Botcazou ebotcazou@adacore.com
Sat Feb 7 10:58:00 GMT 2015


> 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.

-- 
Eric Botcazou



More information about the Gcc-patches mailing list