[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

["jiangning.liu at arm dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

Jiangning Liu <jiangning.liu at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiangning.liu at arm dot
                   |                            |com

--- Comment #35 from Jiangning Liu <jiangning.liu at arm dot com> 2011-04-26 15:13:41 UTC ---
I verified that two patches in #38644 (back end) and #30282 (middle end) both
work for attached cases. Here comes my two cents,

1) The concept of red zone is to control whether instructions can write memory
below current stack frame or not, and it is only being supported by ABIs for
some particular ISAs, so it shouldn't be enabled in middle end by default for
all targets. At this point, middle end should be fixed to avoid doing things
unwanted in general for all targets.

2) Red zone is an orthogonal concept to prologue/epilogue, so it is not good to
fix this issue in prologue/epilogue back end code. At this point, we shouldn't
simply fix it in back end by adding barrier to implicitly disable red zone.
Instead, some hooks should be abstracted in middle end to support it in
scheduling dependence (middle end code). Back end like X86-64 should enable it
through hooks by itself. 

The key here is red zone should be a clean feature to be supported in middle
end. Exposing this kind of stuff to back end through hooks can improve code
quality for middle end and avoid bringing the bugs to back-end. 

This bug has long history, and it is being now or has ever been exposed on ARM,
POWER and X86(with some options combination). Fixing it in middle end is not
only a bug fix, but a simple infrastructure improvement. Due to the long
duration and the extensive impact for different targets, I don't see good
reason of not fixing it in mainline ASAP.