This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA][PATCH][middle-end/53623] Improve extension elimination
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 20 Dec 2013 18:25:19 +0100
- Subject: Re: [RFA][PATCH][middle-end/53623] Improve extension elimination
- Authentication-results: sourceware.org; auth=none
- References: <52B3CE40 dot 6090103 at redhat dot com> <20131220082441 dot GC892 at tucnak dot redhat dot com> <52B46FA2 dot 40004 at redhat dot com> <20131220164520 dot GJ892 at tucnak dot redhat dot com> <52B47B96 dot 9060203 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Dec 20, 2013 at 10:17:10AM -0700, Jeff Law wrote:
> ISTM if we're presented with something like that (and I don't think
> there's anything in RA which explicitly disallows such code), then
> what we have to evaluate is whether or not the transformation
> preserves the semantics.
>
> So, incoming would look like this (assuming a 32 bit target):
>
>
> r1:SI = mem:SI
> r2:DI = sext:DI (r1:SI)
> [ Use r2/r3 ]
> r1:DI = zext:DI (r1:SI)
>
> And that would be transformed into:
>
> r2:DI = sext:DI (mem:SI)
> r1:DI = r2:DI
> [ Use r2/r3 ]
> r1:DI = zext:DI (r1:SI)
>
> Where r2 will have the wrong value in the use statements. ISTM we
> can check for an overlap between the destination of the memory load
> and the destination of the first extension. Right?
>
> Is that the case you're worrying about?
Yes. So my suggestion actually was not correct for that:
&& !reg_overlap_mentioned_p (dest, XEXP (src, 0))
because the first extension above has r1:SI and r2:DI which don't
overlap, only r1:DI and r2:DI overlap. So it probably should be checked
in combine_reaching_defs instead where you have already both the registers
in the right modes available and can call reg_overlap_mentioned_p on them
directly. One argument would be SET_DEST (def_insn) and one SET_DEST
(cand->insn), right?
Jakub