patch for mips flow problem, including test case
Jeffrey A Law
law@cygnus.com
Wed Oct 7 23:04:00 GMT 1998
In message < tx1pvc3am49.fsf@cygnus.com >you write:
>
> > The addition of (use (label)) to tablejumps is an anachronism. That was
> > necessary in the early days, but it has been unnecessary ever since the
> > REG_LABEL reg notes were added.
>
> The USE method is the only way used by rtlanal.c:computed_jump_p,
> which is used by flow, to distinguish tablejumps from generic computed
> jumps.
But we could just as easily identify tablejumps by an ADDR_VEC/ADDR_DIFF_VEC.
That's how Cygnus's block merging code and edge splitting code identifies
table jumps.
Actually I wouldn't mind looking into attaching the ADDR_VEC/ADDR_DIFF_VEC
to the tablejump insn itself. It would avoid two ugly problems:
* flow current puts the tablejump insn and the ADDR_DIFF/ADDR_DIFF_VEC
into different basic blocks (which causes problems for gcse, block
merging, and edge splitting)
* If we stop flow from putting them in different blocks, then we have
be concerned about code which assumes that it won't find a JUMP_INSN
except at the end of a block (the scheduler comes immediately to mind).
> The notes on REG_LABEL in rtl.h emphasize its use in non-jump insns.
> If it can be used in a jump insn to indicate the associated table,
> that should be indicated there. Might we want labels on tables of
> addresses to be handled differently from labels that would be targets
> of jumps or address-of-code-label operations?
If we can differentiate them, it can help when building the cfg and with
optimizers/analyzers which work on the cfg like egde splitting and block
merging.
> > There are a number of ports nowadays that
> > don't bother to include the (use (label)) in tablejump patterns. The MIP
> S
> > is one. PA is another (see the casesi0 pattern). There may be others.
>
> Okay, then the PA will probably fail the test case I added, if casesi0
> gets used.
It does get used. :-) It's due for another rewrite though. The current code
is extremely unfriendly to the dynamic branch prediction scheme on the PA8000
class processors.
jeff
More information about the Gcc-patches
mailing list