> 1. For cmp/test with rip-relative addressing mem operand, don't group > insns. Bulldozer also doesn't support fusion for cmp/test with both > displacement MEM and immediate operand, while m_CORE_ALL doesn't > support fusion for cmp/test with MEM and immediate operand. I simplify > choose to use the more stringent constraint here (m_CORE_ALL's > constraint).
This suits Bulldozer's specification. We don't see an issue with the proposed patch. Regards Ganesh -----Original Message----- From: H.J. Lu [mailto:hjl.to...@gmail.com] Sent: Wednesday, September 25, 2013 2:12 AM To: Wei Mi Cc: Jan Hubicka; Alexander Monakov; Steven Bosscher; GCC Patches; David Li; Kirill Yukhin Subject: Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion On Tue, Sep 24, 2013 at 12:06 PM, Wei Mi <w...@google.com> wrote: > This is the updated patch2. > Changed: > 1. For cmp/test with rip-relative addressing mem operand, don't group > insns. Bulldozer also doesn't support fusion for cmp/test with both > displacement MEM and immediate operand, while m_CORE_ALL doesn't > support fusion for cmp/test with MEM and immediate operand. I simplify > choose to use the more stringent constraint here (m_CORE_ALL's > constraint). > 2. Add Budozer back and merge TARGET_FUSE_CMP_AND_BRANCH_64 and > TARGET_FUSE_CMP_AND_BRANCH_32. > > bootstrap and regression pass. ok for trunk? > > 2013-09-24 Wei Mi <w...@google.com> > > * gcc/config/i386/i386.c (rip_relative_addr_p): New Function. > (ix86_macro_fusion_p): Ditto. > (ix86_macro_fusion_pair_p): Ditto. > * gcc/config/i386/i386.h: Add new tune features about macro-fusion. > * gcc/config/i386/x86-tune.def (DEF_TUNE): Ditto. > * gcc/doc/tm.texi: Generated. > * gcc/doc/tm.texi.in: Ditto. > * gcc/haifa-sched.c (try_group_insn): New Function. > (group_insns_for_macro_fusion): Ditto. > (sched_init): Call group_insns_for_macro_fusion. > * gcc/sched-rgn.c (add_branch_dependences): Keep insns in > a SCHED_GROUP at the end of BB to remain their location. > * gcc/target.def: Add two hooks: macro_fusion_p and > macro_fusion_pair_p. > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index > 1fd3f60..4a04778 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -24856,6 +24856,167 @@ ia32_multipass_dfa_lookahead (void) > } > } > > +/* Extracted from ix86_print_operand_address. Check whether ADDR is a > + rip-relative address. */ > + > +static bool > +rip_relative_addr_p (rtx addr) > +{ > + struct ix86_address parts; > + rtx base, index, disp; > + int ok; > + > + if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_VSIBADDR) > + { > + ok = ix86_decompose_address (XVECEXP (addr, 0, 0), &parts); > + parts.index = XVECEXP (addr, 0, 1); > + } > + else if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_LEA_ADDR) > + ok = ix86_decompose_address (XVECEXP (addr, 0, 0), &parts); else > + ok = ix86_decompose_address (addr, &parts); > + > + gcc_assert (ok); > + base = parts.base; > + index = parts.index; > + disp = parts.disp; > + > + if (TARGET_64BIT && !base && !index) > + { > + rtx symbol = disp; > + > + if (GET_CODE (disp) == CONST > + && GET_CODE (XEXP (disp, 0)) == PLUS > + && CONST_INT_P (XEXP (XEXP (disp, 0), 1))) > + symbol = XEXP (XEXP (disp, 0), 0); > + > + if (GET_CODE (symbol) == LABEL_REF > + || (GET_CODE (symbol) == SYMBOL_REF > + && SYMBOL_REF_TLS_MODEL (symbol) == 0)) > + return true; > + } > + if (flag_pic && !base && !index) > + { > + if (GET_CODE (disp) == CONST > + && GET_CODE (XEXP (disp, 0)) == UNSPEC > + && (XINT (XEXP (disp, 0), 1) == UNSPEC_PCREL > + || XINT (XEXP (disp, 0), 1) == UNSPEC_GOTPCREL > + || (TARGET_64BIT > + && XINT (XEXP (disp, 0), 1) == UNSPEC_GOTNTPOFF))) > + return true; > + } > + return false; > +} > + It doesn't look right. IP relative address is only possible with TARGET_64BIT and 1. base == pc. Or 2. UUNSPEC_PCREL, UNSPEC_GOTPCREL, and NSPEC_GOTNTPOFF. -- H.J.
