Re: Question about CASE_DROPS_THROUGH

[Roger Sayle <roger at eyesopen dot com>]

On Sun, 20 Jun 2004, Zack Weinberg wrote:
> So how would I do it?  I'd embed the addr_vec/addr_diff_vec inside the
> insn that refers to it.  For x86,
>
> (insn 13 83 14 2 (set (reg/f:SI 61)  ; this loads the address of the
>       (addr_vec:SI [                 ; addr_vec, which is off in .rodata
>             (label_ref:SI 25)
>             (label_ref:SI 31)
>             (label_ref:SI 37)
>             (label_ref:SI 43)
>             (label_ref:SI 49)
>             (label_ref:SI 55)
>             (label_ref:SI 61)
>             (label_ref:SI 67)
>         ]) -1 (nil)
>     (nil)))
>
> (insn 14 13 15 2 (set (reg:SI 62)
>         (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 60 [ x ])
>                     (const_int 4 [0x4]))
>                 (reg/f:SI 61)) [0 S4 A8])) -1 (nil)
>     (nil))
>
> (jump_insn 15 14 16 2 (set (pc)
>        (reg:SI 62)) -1 (nil)
>     (nil))


I'll admit that this looks like a major improvement over what we
have now, and is closer to the semantics of our new SWITCH_EXPR.
The only difficulty I see is that the addr_vec is not easily
accessible for the the jump_insn, so building an accurate CFG is
made harder.  For example, there's nothing to prevent insn 13
above being hoisted out of a loop, or even CSE'd such that
two switches/indirect jumps share the same jump table [both of
which I consider to be good things].  And not just CFG building,
redirect_edge and friends would need to locate the addr_vec.

One way to keep the association between between the actual control
flow instruction (jump_insn) and the addr_vec-containing instruction
is to perhaps attach a NOTE to the jump_insn referencing the "load".
The VAX that keeps the addr_vec and the jump_insn together doesn't
need such a note.  Or perhaps some form of RTL sharing.

Alternatively, we could just pessimize the CFG and allow edges
from the indirect jump to every potentially reachable label in
the current function, as we do for "generic" indirect jumps.

Maybe the CFG folks have some thoughts.

Roger
--