Hi!
On Fri, May 28, 2021 at 11:48:06AM +0200, Martin Liška wrote:
> There's a fallout after my revision
> ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e. I would like to analyze
> all case and discuss possible solution. To be honest it's a can of worms
> and reverting the commit
> is an option on the table.
> $ ./xgcc -B. -Os pr.C
> pr.C:2:11: internal compiler error: ‘global_options’ are modified in
> local context
> 2 | void main();
So what is called "global" and "local" there? There are at least three
levels (cannot modify within a TU, cannot modify within a function, and
anything goes). What is this about?
> What happens: we change from -Os to -O0 and rs6000_isa_flags differ in
> cl_optimization_compare.
> Problem is that OPTION_MASK_SAVE_TOC_INDIRECT is set based on optimize flag:
>
> /* If we can shrink-wrap the TOC register save separately, then use
> -msave-toc-indirect unless explicitly disabled. */
> if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
> && flag_shrink_wrap_separate
> && optimize_function_for_speed_p (cfun))
> rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
Why is that a problem? This has always been allowed, and disallowing it
now will have a lot of fallout. Why change the basic features of the
model at all, is there a very good reason for that?
> This is caused by a weird option override:
>
> else if (rs6000_long_double_type_size == 128)
> rs6000_long_double_type_size = FLOAT_PRECISION_TFmode; (it's 127)
This is a workaround for the fact that GCC insists all floating point
types can be ordered. They can not. There are numbers in both
double-double ("IBM extended long double") and in IEEE QP float that
cannot be represented with the same precision in the other format. So
Mike made GCC think one format is "better" than the other depending on
which we default to. This hack works remarkably well, but is of course
a hack. Until the generic problems here are fixed we cannot do better.
> later when rs6000_option_override_internal is called for saved target flags
> (127), it complains.
> Possible fix:
>
> else if (rs6000_long_double_type_size == 128
> || rs6000_long_double_type_size == FLOAT_PRECISION_TFmode)
Please propose that as separate patch, and/or open a PR for it. Having
everything in one mail thread might be easiest for you, but it isn't for
everyone else ;-)
> What target maintainers thing about it?
That we need a lot more background: what do you want to do, and why?
Segher
