This is the mail archive of the
mailing list for the GCC project.
Re: [avr] fno-caller-saves and regression tests
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>
- Cc: gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 12 Aug 2016 11:42:17 +0200
- Subject: Re: [avr] fno-caller-saves and regression tests
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On 09.08.2016 07:33, Senthil Kumar Selvaraj wrote:
Turning off -fcaller-saves for AVR makes the testcase I had for PR 71873
pass unless I explicitly add -fcaller-saves to force the compiler to
generate the triggering insn patterns.
Wonder if we should modify the existing test cases in gcc.target/avr to
be tested both ways (with and without caller saves)? At least the
register allocation related ones probably won't catch regressions.
Testing both way makes only sense, IMO, if we actually "support" -fcaller-saves
and if someone is going to fix reg alloc bugs.
The current live cycle of such ICEs is:
1) Someone reports register alloc ICE to bugzilla
2) It's not fixed because there are no resources
3) Bug is closed because life cycle of gcc branch ends
4) Problem pops up on newer branch and with different test case
5) goto 1)
I am already very happy if RA ICEs for default options get fixed.
Many thanks to you for digging into that difficult matter.
Re you original question, I am fine with whatever approach the one that gets
involved with these RA bugs will prefer.
From my experience, caller-saves degrades code quality and increases
probability of ICEs from reload. If -fcaller-saves makes it easier for you to
hunt or monitor respective bugs, feel free to adjust the test cases. Or you
might consider adding -fcaller-saves variant(s) to your torture options.