[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #17 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a9a0d654006df98dd2c29b907c83571819c49727
commit r10-9218-ga9a0d654006df98dd2c29b907c83571819c49727
Author: Jakub Jelinek
Date: Tue Dec 8 15:44:10 2020 +0100
i386: Fix up X87_ENABLE_{FLOAT,ARITH} in conditions [PR94440]
The documentation says
For a named pattern, the condition may not depend on the data in
the insn being matched, but only the target-machine-type flags.
The i386 backend violates that by using flag_excess_precision and
flag_unsafe_math_optimizations in the conditions too, which is bad
when optimize attribute or pragmas are used. The problem is that the
middle-end caches the enabled conditions for the optabs for a particular
switchable target, but multiple functions can share the same
TARGET_OPTION_NODE, but have different TREE_OPTIMIZATION_NODE with
different
flag_excess_precision or flag_unsafe_math_optimizations, so the enabled
conditions then match only one of those.
I think best would be to just have a single options node for both the
generic and target options, then such problems wouldn't exist, but that
would be very risky at this point and quite large change.
So, instead the following patch just shadows flag_excess_precision and
flag_unsafe_math_optimizations values for uses in the instruction
conditions
in TargetVariable and during set_cfun artificially creates new
TARGET_OPTION_NODE if flag_excess_precision and/or
flag_unsafe_math_optimizations change from what is recorded in their
TARGET_OPTION_NODE. The target nodes are hashed, so worst case we can get
4
times as many target option nodes if one would for each unique target
option
try all the flag_excess_precision and flag_unsafe_math_optimizations
values.
2020-12-08 Jakub Jelinek
PR target/94440
* config/i386/i386.opt (ix86_excess_precision,
ix86_unsafe_math_optimizations): New TargetVariables.
* config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): Use
ix86_unsafe_math_optimizations instead of
flag_unsafe_math_optimizations and ix86_excess_precision instead of
flag_excess_precision.
* config/i386/i386.c (ix86_excess_precision): Rename to ...
(ix86_get_excess_precision): ... this.
(TARGET_C_EXCESS_PRECISION): Define to ix86_get_excess_precision.
* config/i386/i386-options.c (ix86_valid_target_attribute_tree,
ix86_option_override_internal): Update
ix86_unsafe_math_optimization
from flag_unsafe_math_optimizations and ix86_excess_precision
from flag_excess_precision when constructing target option nodes.
(ix86_set_current_function): If flag_unsafe_math_optimizations
or flag_excess_precision is different from the one recorded
in TARGET_OPTION_NODE, create a new target option node for the
current function and switch to that.
(cherry picked from commit e401db7bfd8cf86d3833805a81b1252884eb1c9d)
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 Jeffrey A. Law changed: What|Removed |Added Target Milestone|8.5 |11.0 CC||law at redhat dot com
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #6 from Jakub Jelinek --- Guess we should defer for GCC11 then, and figure out a way what OPTIMIZATION_NODE flags could be relevant for target globals (guess the vast majority isn't, most of them will be flags affecting FE or GIMPLE optimizations or what RTL passes are enabled/disabled), mark them some way in *.opt files and figure out how to force a new target node (or hash that) on switchable targets if any of those options changes.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92860 --- Comment #5 from Martin Liška --- We do have quite some known issues in PR92860 where a target optimization influences optimization options (and vice versa). I tried to fix some of them but yes, it's really a mess and non-trivial.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 --- Comment #4 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #2) > So, either we need to consider also -ffast-math options to be part of target > and force different this_target_recog if it changes between functions, or > the i386 backend can't use enabled attribute for the fast-math dependent > checks. By reverting the referred change, we risk PR78738. Considering that -ffast-math flags are not current optimization level flags, I'd vote for handling these flags.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
BTW, given that -fexcess-precision= option is marked Optimization, I'd say this
has been a problem even before that commit and one could construct a testcase
where it triggers.
Like one function with __attribute__((optimize ("excess-precision=standard")))
and another one with __attribute__((optimize ("excess-precision=fast"))).
Though, target-globals.[ch] seems to have some (limited?) support also for
optimization_current_node, but it probably isn't invoked on changes to just
optimize attribute and no target attributes changes and not sure if it deals
correctly with target and optimize attribute changes etc. What a mess.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #2 from Jakub Jelinek ---
I need -mfpmath=sse,387 -fexcess-precision=standard -Ofast -msse2
--param=scev-max-expr-size=0 -m32 (-Werror not needed, but -msse2 required) to
reproduce.
The function suggests that the "enabled" attribute on the pattern in question
(*fop_df_comm) violates the documented rules:
"All these attributes should use @code{(const_int 1)} to allow an alternative
or @code{(const_int 0)} to disallow it. The attributes must be a static
property of the subtarget; they cannot for example depend on the
current operands, on the current optimization level, on the location
of the insn within the body of a loop, on whether register allocation
has finished, or on the current compiler pass."
Seems like the target is the same for both functions - in particular
this_target_recog is the same between f1 and main - default_target_recog in
both cases (the two functions don't have different target attribute).
So, either we need to consider also -ffast-math options to be part of target
and force different this_target_recog if it changes between functions, or the
i386 backend can't use enabled attribute for the fast-math dependent checks.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440
--- Comment #1 from Uroš Bizjak ---
Are you sure the bisection is correct?
Fairly current gcc-8 and gcc-9 branches work OK for me, but bisection points to
gcc-7 commit.
Also, I don't see anything wrong with the failing pattern:
#2 0x006ac8f1 in check_bool_attrs (insn=insn@entry=0x7fffea817980) at
/home/uros/git/gcc/gcc/recog.c:1614
1614 gcc_unreachable ();
(gdb) p debug_rtx (insn)
(insn 10 9 11 3 (set (reg:DF 83 [ d_lsm.12 ])
(plus:DF (reg:DF 83 [ d_lsm.12 ])
(mem:DF (plus:DI (mult:DI (reg:DI 87 [ i ])
(const_int 8 [0x8]))
(reg/f:DI 7 sp)) [2 a S8 A64]))) "pr94440.c":12:7 904
{*fop_df_comm}
(expr_list:REG_DEAD (reg:DI 87 [ i ])
(nil)))
$1 = void
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.5
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ubizjak at gmail dot com Last reconfirmed||2020-04-01
