Reload with jump_insn that have a 'set' side effect.

Hendrik Greving hendrik.greving.intel@gmail.com
Tue Sep 17 16:22:00 GMT 2013


Hi,

For a special mechanism we are generating jump_insn with a 'set' side
effect in our backend. RTL looks e.g. like this:

(jump_insn 25 24 26 (nil) (parallel [
            (set (pc)
                (if_then_else (ne (unspec_volatile [
                                (const_string ("<myinsn> %0,[%1] =%2"))
                                (const_int 0 [0x0])
                                (reg:SI 348)
                            ] 21)
                        (const_int 0 [0x0]))
                    (label_ref:SI 43)
                    (pc)))
            (clobber (reg:SI 321 link))
            (set (reg/v:QI 346)
                (unspec:QI [
                        (const_int 0 [0x0])
                    ] 0))
        ]) -1 (nil)
    (nil))

After working out some issues initially, this all works fine and the
'set' seems to be properly recognized by RTL optimization phases (e.g.
CSE). I am now running into an issue however with reload. The problem
seems to be that if the parallel 'set' from e.g. RTL above feeds into
a (mem (reg)). This happens when e.g. compiling in debug mode, most
variables are at memory locations of the stack. In this case, compiler
needs to reload the instruction above (I am actually not sure why, but
I guess this could happen all the time). The further problem seems to
be that there is a hard constraint in reload that jump_insn can't have
output operands / reloads.

if (GET_CODE (insn) == JUMP_INSN || GET_CODE (insn) == CALL_INSN)
    no_output_reloads = 1;

so what I am doing is, when generating RTL above, I always 'reload'
myself in the backend, generating mov's to/from memory, and always
making sure only hard registers are put into RTL above. The problem is
that I need hard registers for that. I would strongly prefer using
pseudo's, but pseudo's also seem to require reload.

Is there any way to enable above to be able to be supported in 'reload'?

Best Regards,
Hendrik Greving



More information about the Gcc mailing list