This is the mail archive of the
mailing list for the GCC project.
Re: [RFC 0/6] Flags outputs for asms
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "H. Peter Anvin" <hpa at zytor dot com>, law at redhat dot com, gcc-patches at gcc dot gnu dot org, peterz at infradead dot org, torvalds at linux-foundation dot org, jakub at redhat dot com
- Date: Fri, 8 May 2015 16:14:02 -0500
- Subject: Re: [RFC 0/6] Flags outputs for asms
- Authentication-results: sourceware.org; auth=none
- References: <1431034740-5375-1-git-send-email-rth at redhat dot com> <554C0E31 dot 5070509 at zytor dot com> <554CDC30 dot 1080903 at redhat dot com> <554D195D dot 4010508 at redhat dot com>
On Fri, May 08, 2015 at 01:15:25PM -0700, Richard Henderson wrote:
> But it *does* try to match an intermediate pattern,
> (set (reg:CCGC 17 flags)
> (compare:CCGC (reg:CCGC 17 flags)
> (const_int 0 )))
> which can be considered a no-op move.
Maybe we should teach combine this is a no-op, then? Then everything
should work as-is? Combine knows about no-op moves (they don't cost,
and it deletes them itself).
> Jeff or Segher, is it worth complicating the can_combine_p test near line 1958
> /* Make sure that the value that is to be substituted for the register
> does not use any registers whose values alter in between. However,
> If the insns are adjacent, a use can't cross a set even though we
> think it might (this can happen for a sequence of insns each setting
> the same destination; last_set of that register might point to
> a NOTE). If INSN has a REG_EQUIV note, the register is always
> equivalent to the memory so the substitution is valid even if there
> are intervening stores. Also, don't move a volatile asm or
> UNSPEC_VOLATILE across any other insns. */
> || (! all_adjacent
> && (((!MEM_P (src)
> || ! find_reg_note (insn, REG_EQUIV, src))
> && use_crosses_set_p (src, DF_INSN_LUID (insn)))
> || (GET_CODE (src) == ASM_OPERANDS && MEM_VOLATILE_P (src))
> || GET_CODE (src) == UNSPEC_VOLATILE))
> to notice that the set is one of SUCC or SUCC2, and is thus included in the
> insns being combined? That does seem cleaner and more general than the hacky
> i386 nop_cmp pattern, but would certainly require tons more testing...
"Cleaner"? In this code? Heh.
use_crosses_set_p often estimates pessimistically. Is that what is
happening here? Using real dataflow in combine would fix that (and many
other problems). Not that that helps you right now ;-)
I'll build with your patches tomorrow and investigate.