This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch i386]: Fix PR/46219 Generate indirect jump instruction
- From: Kai Tietz <ktietz at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Tue, 3 Jun 2014 16:15:31 -0400 (EDT)
- Subject: Re: [patch i386]: Fix PR/46219 Generate indirect jump instruction
- Authentication-results: sourceware.org; auth=none
- References: <1705189073 dot 20810228 dot 1401825417250 dot JavaMail dot zimbra at redhat dot com> <538E2ACC dot 5070403 at redhat dot com>
----- Original Message -----
> On 06/03/2014 12:56 PM, Kai Tietz wrote:
> > +(define_insn "*sibcall_intern"
> > + [(call (unspec [(mem:QI (match_operand:W 0 "memory_operand"))]
> > UNSPEC_PEEPSIB)
> > + (match_operand 1))]
> > + ""
> > + "* SIBLING_CALL_P (insn) = 1; return ix86_output_call_insn (insn,
> > operands[0]);"
> > + [(set_attr "type" "call")])
>
> Why would this be hard to do when first emitting it?
To set this flag on the peephole causes some hazard with unknown-instruction, as the memory isn't part of the existing SIBLING_CALL_P (insn) rules. And of course we don't want to allow general memory-operand for sibling-calls, so it is hard (and useless) to set it in peephole. Additionally it would mean to replace insn-generation generation by hand-written block to get access to the insn (code generation adds added { ... } block to the beginning of the peephole-generation routine).
> > +; TODO
> > +(define_peephole2
> > + [(set (match_operand:DI 0 "register_operand")
> > + (match_operand:DI 1 "memory_operand"))
> > + (unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)]
> > + "TARGET_64BIT"
> > + [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
> > + (set (match_dup 0)
> > + (match_dup 1))])
> > +
> > +(define_peephole2
> > + [(set (match_operand:SI 0 "register_operand")
> > + (match_operand:SI 1 "memory_operand"))
> > + (unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)]
> > + "!TARGET_64BIT"
> > + [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)
> > + (set (match_dup 0)
> > + (match_dup 1))])
>
> These are wrong. This allows unrestricted movement across the blockage.
Well, I didn't noticed any serious regression by it. Anyway I will add blockage-check to sibcall-pattern.
> > +(define_peephole2
> > + [(set (match_operand:DI 0 "register_operand")
> > + (match_operand:DI 1 "memory_operand"))
> > + (call (mem:QI (match_operand:DI 2 "register_operand"))
> > + (match_operand 3))]
> > + "TARGET_64BIT && REG_P (operands[0])
> > + && REG_P (operands[2])
> > + && SIBLING_CALL_P (peep2_next_insn (1))
> > + && REGNO (operands[0]) == REGNO (operands[2])"
> > + [(call (unspec [(mem:QI (match_dup 1))] UNSPEC_PEEPSIB) (match_dup 3))])
>
Kai