Jeff Law schrieb:
On Wed, 2019-12-18 at 16:30 +0100, Georg-Johann Lay wrote:
Hi, this patch turns off -fipa-icf-variables because it generates wrong
code like for PR92606. As there is no target hook that could decide
whether such optimizations are obsolete, disable such optimizations
alltogether until PR92932 (target hook to disable such optimizations
depending on object attributes and address-spcace) is available.
Ok to apply?
Johann
Work around PR ipa/92932 by disabling -fipa-icf-variables until
PR92932 will have been solved.
PR ipa/92932
PR target/92606
* common/config/avr/avr-common.c (avr_option_optimization_table)
<-fipa-icf-variables>: Disable.
This seems backwards to me. Instead of disabling the optimization in
the target files we should prevent the optimization from firing in
cases where it can't reasonably work.
Jeff
The chances that this will be fixed are... tiny. As Andrew notes in a
comment to PR92932, there are at least 2 other PRs that report
wrong-code due to similar data optimization. He mentions different
passes however.
Whatever passes perform such wrong-code transforms, apart from more
conservative approach they will need a new target hook to properly fix
PR92606 because target attributes / address spaces are involved.
I'd highly appreciate correct code, even if it's at the expense of (yah,
yet another) hack in the avr backend. In particular, because such
optimizations will improve code only a tiny little bit -- if at all.
Hence kicking out the culprit does not reduce code quality, also because
IF such merging is legitimate, some cases can be catched by the linker
with, say -fmerge-all-constants.
If PR92932, PR92294, PR954666 will ever be fixed, I'd gladly remove the
proposed 1-line disable-culprit-hack and implement the new target hook
that PR92932 is supposed to bring.
Johann
