> The main point of having rtl epilogues is to allow such optimizations. > Traditionally, we have said that at -O1, it is OK to curb optimizations for > the > sake of having programs that are saner to debug, while -O2 and above should > just optimize, and the debug info generation is just thrown in afterwards as a > best-effort attempt. > > Additionally, we also have -Og now.
Well, it seems to me that we prefer to disable optimizations when talking about debug related information (see PR target/60598 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@208749 138bc75d-0d04-0410-961f-82ee72b054a4 commit). > > You can also consider having separate options to control optimizations that > affect debugging. > If leaving out epilogue cfi is what it takes to allow epilogue scheduling > without the compiler crashing, then that is what should be done by default at > -O2, but if someone finds that particularly vexing, they might appreciate a - > mepilogue-cfi option to change that default, and instead disable some > scheduling (delay slot and otherwise). Unfortunately, dwarf2cfi checks the paths for consistency (dwarf2cfi.c:2284), throwing an error if those paths are not ok. Also, with ARC gcc we focus on Linux type of application, hence, the unwinding info needs to be consistent. As far as I can see, having a sort of mno-epilogue-cfi option will just inhibit or not the emitting of the blockage instruction, and the option will be valid only when compiling without emitting dwarf information (i.e., the mno-epilogue-cfi is incompatible with -g). Personally, I do not see the benefit of having such an option, as one may lose like 1 cycle per function call (HS/EM cpus) in very particular cases. Running the dg.exp, compile.exp, execute.exp, and builing Linux with some default apps, we found only 4 cases in which the branch scheduler slot needs the blockage mechanism. Also, adding blockage before generating any prologue instruction seems to be a wide spread practice in gcc backends (see SH for example). Best, Claudiu
