This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
- From: Jeff Law <law at redhat dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 26 Nov 2013 15:59:28 -0700
- Subject: Re: [RFC][PR middle-end/59285] builtin-unreachable-6 on ARM
- Authentication-results: sourceware.org; auth=none
- References: <5294F468 dot 1060006 at redhat dot com> <CABu31nP1mMa8FPBxsOb9scL9H3Q2NTznN3UETwEpSYiNLgEN=Q at mail dot gmail dot com> <52950CA2 dot 40607 at redhat dot com> <CABu31nOHRj7OYMdVqwRVuQPdphwCA6K2SGd2buY_e1foGaZUAg at mail dot gmail dot com> <52951B37 dot 4030305 at redhat dot com> <CABu31nNqpyegnCVj6md=+MrF27H-STFzVM=d93iuLxZo+V13EQ at mail dot gmail dot com>
On 11/26/13 15:44, Steven Bosscher wrote:
So we have a block which calls fubar. The block would have no successors.
And I think we're right back in the same situation. We're going to have a
BARRIER after that block with no successors and ifcvt is going to muck
things up tripping the checking failure.
In RTL-land the NORETURN flag is already a statement thing via
REG_NORETURN. But I'm not sure if such a note is added for calls
followed originally by a builtin_unreachable. I'm guessing "not".
I'm not aware of any code to do that.
Also note that we could get the same behaviour from a
*<magicaddr> = magicnum
if we were talking to a special piece of hardware. Though perhaps we
wouldn't if-convert the volatile memory reference.
Exactly why I ultimately came up with the hack I posted rather than the
hack to cond_exec_find_if_block which was my original fix.
And yet, that's what merge_if_blocks will do if you remove the
BARRIER. You're basically closing the diamond so that the conditional
jump can be optimized away. That's a good thing, of course.
But it seems arbitrary to do it in ifcvt.c and only for cond_exec
targets. Does the condjump survive to assembler output on e.g. x86_64?
Yup. It lives all the way to assembler output.