On Sat, Feb 07, 2015 at 11:28:54AM +0100, Richard Biener wrote:
> On February 6, 2015 9:26:29 PM CET, Jakub Jelinek <ja...@redhat.com> wrote:
> >Hi!
> >
> >As mentioned in the PR, the problem here is that the Ada FE needs to
> >modify
> >global_options after toplevel.c (process_options), but as for LTO we
> >now use
> >optimization_{default,current}_node for options of functions without
> >specifial optimization node, it means the changed options aren't
> >reflected
> >in there.
> >
> >Fixed thusly, bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> Can't ada use one of the option processing langhooks or represent this change
> similar to optimization pragmas in other frontends?
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.
Jakub
