This is the mail archive of the
mailing list for the GCC project.
Re: peephole2: dead regs not marked as dead
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: Georg Lay <avr at gjlay dot de>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 10 Nov 2010 12:43:22 +0100
- Subject: Re: peephole2: dead regs not marked as dead
- References: <4CC1729C.email@example.com> <4CC93592.firstname.lastname@example.org> <4CC96A31.email@example.com> <4CC97656.firstname.lastname@example.org> <4CC9C7A0.email@example.com> <4CCAE383.firstname.lastname@example.org> <4CCAE571.email@example.com> <4CCAF3BF.firstname.lastname@example.org> <4CCAF81D.email@example.com> <4CCFDCDD.firstname.lastname@example.org> <20101108202705.GB14062@hungry-tiger.westford.ibm.com> <4CDA7AF0.email@example.com>
On 11/10/2010 11:58 AM, Georg Lay wrote:
In the old 3.4.x (private port) I introduced a target hook in combine,
just prior to where recog_for_combine gets called. The hook did some
canonicalization of rtx and thereby considerably reduced the number of
patterns that would have been necessary without that hook. It
transformed some unspecs.
How is that related to delegitimize_address?
A second use case of such a hook could look as follows: Imagine a
combined pattern that does not match but would be legal if the backend
knew that some register contains some specific value like, e.g.,
non-negative, zero-or-storeflagvalue, combiner has proved that some
bits will always be set or always be cleared;
You can use nonzero_bits or num_signbit_copies in define_splits. In
_this_ case, a define_insn_or_split doesn't really help, I agree with
Joern on this. :)
Suppose insns A, B and C with costs f(A) = f(B) = f(C) = 2.
Combine combines A+B and sees costs f(A+B) = 5. This makes combine
reject the pattern, not looking deeper.
Does it really do that? I see nothing in combine_instructions which
would prevent going deeper.