[Bug target/96939] LTO vs. different arm arch options

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Sep 4 19:00:34 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
AFAIK targetm.override_options_after_change is called at the end of switching
optimization (but not target) options.
So, that is a good hook to e.g. adjust something cached from those non-target
Optimization options.
targetm.target_option.save is called during cl_target_option_save,
targetm.target_option.restore during cl_target_option_restore.
Then there is the targetm.set_current_function hook that is called during
set_cfun, i.e. when switching functions.

So, just from quick look, it seems wrong that arm
targetm.override_options_after_change calls arm_configure_build_target which is
a function which deals with target specific options (and furthermore it calls
it with the target_option_default_node node, so the command line options rather
than whatever options the function has).

I see that the rationale is probably that you want TARGET_THUMB to be reliable
for the arm_override_options_after_change_1, but I'd think you instead want to
just call the _1 and nothing else in there, and in arm_set_current_function
(perhaps at the end of it) call it again, so it is updated properly even if the
target options change.  And maybe also call it at the start of
arm_set_current_function even when nothing changed if that isn't sufficient.

I think it was a mistake to have separate OPTIMIZATION_NODE and
TARGET_OPTION_NODE, in retrospect I think that causes a lot of pain and I think
it would be better if there was just one that would hold both and would be
updated together, then have generic code deal with those changes and afterwards
a target hook.
Because when they are separate, at one time only one of them changes, some
hooks are run, then the other one changes and some options/cached variables
etc. can be dependent on both Optimization and Target options.


More information about the Gcc-bugs mailing list