[PATCH] options: Save and restore opts_set for Optimization and Target options

[Jakub Jelinek]

On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus wrote:
> This patch breaks quite a view test cases (target-attribute/tattr-*) on
> IBM Z.  Having a look at function cl_target_option_restore reveals that
> some members of opts_set are reduced to 1 or 0 depending on whether a
> member was set before or not, e.g. for target_flags we have
> 
> opts_set->x_target_flags = (mask & 1) != 0;
> 
> whereas previously those members where not touched by
> cl_target_option_restore.

opts_set is always used as a booleans, cleaner would be to have a 
struct global_option_set that would contain just bool fields (or even
bitfields) with the same names as in struct global_option, but unfortunately
we didn't do that years ago and changing it now would be quite a lot of
work.
Anyway, opts_set records a boolean for each flag, whether it was set
explicitly or not, for non-pointer vars that means values 0 and 1,
for pointer vars NULL and "".
I vaguely remember the s390 opts_set handling differed quite a lot from all
the other targets.

> What puzzles me right now is that in cl_target_option_save we save in
> ptr only options from opts but not from opts_set whereas in
> cl_target_option_restore we override some members of opts_set.  Thus it
> is unclear to me how a backend should restore opts_set then.

I've handled in the generic code handling of the opts_set only for whatever
is handled there for opts too.
Whether the vars that are handled in the save/restore options hooks need
handling of opts_set at all or not depends on whether the backend ever cares
about those or not (e.g. whether it every queries
global_options_set.x_whatever).  If yes, it can be handled e.g. by having an
extra target variable that will store whether it was explicit or not and
restore from there.  If it is never used, then it doesn't need to be
handled.

	Jakub