This is the mail archive of the
mailing list for the GCC project.
Re: Missing barrier in outof_cfglayout
- From: Jeff Law <law at redhat dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 14 May 2015 08:16:45 -0600
- Subject: Re: Missing barrier in outof_cfglayout
- Authentication-results: sourceware.org; auth=none
- References: <5550D693 dot 9000903 at gjlay dot de> <5550DFA5 dot 2000507 at redhat dot com> <5550E8E4 dot 50504 at gjlay dot de> <CABu31nPQH=QY+EgK0bdp1gB_jNrunwEt5XrHq5Jn-WOMn8bKiQ at mail dot gmail dot com> <55521527 dot 10405 at gjlay dot de> <555218AA dot 5060902 at redhat dot com> <555343D0 dot 5040708 at gjlay dot de>
On 05/13/2015 06:30 AM, Georg-Johann Lay wrote:
hmmm, it would actually lead to valid machine code: The jump table is
actually a dispatch table, i.e. it contains a list of direct jumps to
the case labels. casesi loads the value of the label associated with
the jump table into a register, adds an offset, and then jumps to that
address (which in turn dispatches to the very cases via a direct jump).
OK. It's similar to the PA in that regard.
Which is equivalent to jumping to the first entry in the table. OK.
Not great, but OK.
In this specific case cse finds out that the offset (reg 59 below) is
always 0, i.e. the offset computation will always yield the value of the
label associated to the jump table (code_label 84), and then jumps to
That's just avoiding the problem and generating sub-optimal code when
you can collapse the switch to a single case that happens to be the
Other backends are also using dispatch tables and are jumping into the
table, and internal docs for casesi read: "Instruction to jump through a
Wrapping the tablejump's register (reg 60 above) into UNSPEC fixes the
problem, but just because there is no insn to load such an unspec into a
register and hence cse does not perform respective optimization.
I'm not sure offhand -- I'm not real familiar with layoutmode. A quick
scan doesn't show a single routine in cfgrtl.c that would do what we
want. It may be the case that you'll have to cobble it together.
Given the routines from from cfgrtl.c were used: would it then be legal
to jump to a label which is not contained in any basic block?
Conceptually we want to remove all the outgoing edges except the one we
care about. If we do that, try_redirect_by_replacing_jump might "just
work". It's something you'll need to play a bit with to find the right
bits to wire up.