Porting gcc for F-CPU without direct JMP

Porting gcc for F-CPU without direct JMP

[devik]

Hello,

I just tried to port GCC 3.2 to free CPU design
(www.f-cpu.org). The cpu is different in sense that
there is no direct jump (only indirect jump to preloaded
address in register).
When I use:
;;(define_expand "jump"
;; [(set (match_dup 1) (label_ref (match_operand:QI 0 "" "")))
;;  (set (pc) (match_dup 1))]
;;  "" "operands[1]=gen_reg_rtx(Pmode);")

it fails during jump optimization while simplifying complex
jumps into simpler ones - endless loop ! I break it:
#0  0x080c120e in gen_sequence () at emit-rtl.c:4620
#1  0x081176bc in gen_jump (operand0=0x4014f708) at insn-emit.c:1392
#2  0x080a63ed in try_redirect_by_replacing_jump (e=0x82d61ac,
target=0x82d60f0) at cfgrtl.c:735
#3  0x080a6632 in redirect_edge_and_branch (e=0x82d61ac, target=0x82d60f0)
at cfgrtl.c:832
#4  0x081b10ef in try_optimize_cfg (mode=17) at cfgcleanup.c:1658

Basically it prevents all non-constant target jumps to be optimized
because jump redirecting needs to change the label constant in jump insn.
Handling jump at assembler is not the ideal way because the
address load insn has some latency which can be hidden by
gcc scheduler. Also it can pull invariant address load out
of the loops.
I was thinking (and I'd appreciate your comments) about changing
jump.c in such way that it looks for appropriate label constant
load insn (probably pointer from jump insn) and does the label change
there.
But I'm not sure if is it enough :( Can someone give me some
hints ?

thanks, devik

Re: Porting gcc for F-CPU without direct JMP

[Jan Hubicka]

> Hello,
> 
> I just tried to port GCC 3.2 to free CPU design
> (www.f-cpu.org). The cpu is different in sense that
> there is no direct jump (only indirect jump to preloaded
> address in register).
> When I use:
> ;;(define_expand "jump"
> ;; [(set (match_dup 1) (label_ref (match_operand:QI 0 "" "")))
> ;;  (set (pc) (match_dup 1))]
> ;;  "" "operands[1]=gen_reg_rtx(Pmode);")
> 
> it fails during jump optimization while simplifying complex
> jumps into simpler ones - endless loop ! I break it:
> #0  0x080c120e in gen_sequence () at emit-rtl.c:4620
> #1  0x081176bc in gen_jump (operand0=0x4014f708) at insn-emit.c:1392
> #2  0x080a63ed in try_redirect_by_replacing_jump (e=0x82d61ac,
> target=0x82d60f0) at cfgrtl.c:735
> #3  0x080a6632 in redirect_edge_and_branch (e=0x82d61ac, target=0x82d60f0)
> at cfgrtl.c:832
> #4  0x081b10ef in try_optimize_cfg (mode=17) at cfgcleanup.c:1658
> 
> Basically it prevents all non-constant target jumps to be optimized
> because jump redirecting needs to change the label constant in jump insn.
> Handling jump at assembler is not the ideal way because the
> address load insn has some latency which can be hidden by
> gcc scheduler. Also it can pull invariant address load out
> of the loops.
> I was thinking (and I'd appreciate your comments) about changing
> jump.c in such way that it looks for appropriate label constant
> load insn (probably pointer from jump insn) and does the label change
> there.
> But I'm not sure if is it enough :( Can someone give me some
> hints ?
Representing jumps as indirect jumps won't work.  Indirect jumps are
different from direct jumps in a way that they create abnormal edges.
No one expect from try_redirect functions to introduce these.  Even if
this worked, it will be overkill performance wise - GCC will
lose track of what is going on and build complete graph as CFG for each
function breaking most of optimizations.

BTW how it can get into redirecting of edges when all jumps in the
functions are indirect?  Can you take a look how does the flowgraph look
like?

I beleive only sane way is to hide the fact that register is needed
behind the compiler as far as possible.  Probably first insn splitting
pass should introduce the clobbers for address loads and these should
be emit in second insn splitting pass.
This still loses for loops as jump address load can be hoisted outside,
but for getting the port working it may be good enought and we can
improve code quality later.

Honza
> 
> thanks, devik

Re: Porting gcc for F-CPU without direct JMP

[Hans-Peter Nilsson]

On Tue, 10 Dec 2002, devik wrote:

> I just tried to port GCC 3.2 to free CPU design
> (www.f-cpu.org). The cpu is different in sense that
> there is no direct jump (only indirect jump to preloaded
> address in register).

Have a look at the sh64 port hiding inside the sh port.
It has the same trait; it needs branch targets in special branch
target registers.  You should be able to use the same solution.

brgds, H-P

Re: Porting gcc for F-CPU without direct JMP

[devik]

> > I was thinking (and I'd appreciate your comments) about changing
> > jump.c in such way that it looks for appropriate label constant
> > load insn (probably pointer from jump insn) and does the label change
> > there.
> > But I'm not sure if is it enough :( Can someone give me some
> > hints ?
> Representing jumps as indirect jumps won't work.  Indirect jumps are
> different from direct jumps in a way that they create abnormal edges.
> No one expect from try_redirect functions to introduce these.  Even if
> this worked, it will be overkill performance wise - GCC will
> lose track of what is going on and build complete graph as CFG for each
> function breaking most of optimizations.

Thanks for the reply. It seems there is a bit of misunderstanding.
I was thinking about "direct" jumps whose address must be loaded
in registers - but the address will always point to the same label.
So that I think (but not sure) that the samo algorithms in cfg
could be used only when change of label is performed it is not done
in jump insn but in "related" address load (probably previous one
in dataflow).
Like:
a:
add ...
cmp ...
jmp a

will be replaced
a:
add ..
cmp ..
mov a,r1
jmp [r1]

and later optimized:
loadaddr r1 ; get current PC
a:
add ..
cmp ..
jmp [r1]

but all the time is sure that jmp will jump to a (so that
cfg will be the same with the same optimization oportunities).
But I'm not sure with consequences.

> BTW how it can get into redirecting of edges when all jumps in the
> functions are indirect?  Can you take a look how does the flowgraph look
> like?

see above

> I beleive only sane way is to hide the fact that register is needed
> behind the compiler as far as possible.  Probably first insn splitting
> pass should introduce the clobbers for address loads and these should
> be emit in second insn splitting pass.
> This still loses for loops as jump address load can be hoisted outside,

yes. It sounds reasonably. Unfortunately the address load will
be overkill for tight loops. So I'm looking if it CAN ever be
done ...

Martin

Re: Porting gcc for F-CPU without direct JMP

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

On Dec 10, 2002, Hans-Peter Nilsson <hp@bitrange.com> wrote:

> On Tue, 10 Dec 2002, devik wrote:
>> I just tried to port GCC 3.2 to free CPU design
>> (www.f-cpu.org). The cpu is different in sense that
>> there is no direct jump (only indirect jump to preloaded
>> address in register).

> Have a look at the sh64 port hiding inside the sh port.
> It has the same trait; it needs branch targets in special branch
> target registers.  You should be able to use the same solution.

FWIW, the `solution´, that I'm not entirely proud of, is to leave it
up to reload to fix up branches, hope the scheduler will move the PT
instruction sufficiently away from the branches (i.e., no hoisting)
and forbidding branch redirections after reload through the target
hook TARGET_CANNOT_MODIFY_JUMPS_P.

Ideally, we should have tests to tell whether a branch can be
redirected, and even some form of emitting such branches that might
attempt to find a branch-target register available, but I haven't got
that far.  Currently, a lot of code just assumes that branches can be
redirected, and it's then hard to revert the effects when we get to
the point of realizing it was not possible to redirect the branch,
after all.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Porting gcc for F-CPU without direct JMP

[Alexandre Oliva]

On Dec 10, 2002, Hans-Peter Nilsson <hp@bitrange.com> wrote:

> On Tue, 10 Dec 2002, devik wrote:
>> I just tried to port GCC 3.2 to free CPU design
>> (www.f-cpu.org). The cpu is different in sense that
>> there is no direct jump (only indirect jump to preloaded
>> address in register).

> Have a look at the sh64 port hiding inside the sh port.
> It has the same trait; it needs branch targets in special branch
> target registers.  You should be able to use the same solution.

FWIW, the `solution´, that I'm not entirely proud of, is to leave it
up to reload to fix up branches, hope the scheduler will move the PT
instruction sufficiently away from the branches (i.e., no hoisting)
and forbidding branch redirections after reload through the target
hook TARGET_CANNOT_MODIFY_JUMPS_P.

Ideally, we should have tests to tell whether a branch can be
redirected, and even some form of emitting such branches that might
attempt to find a branch-target register available, but I haven't got
that far.  Currently, a lot of code just assumes that branches can be
redirected, and it's then hard to revert the effects when we get to
the point of realizing it was not possible to redirect the branch,
after all.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer