On Tue, May 08, 2007 at 07:41:55AM -0700, Ian Lance Taylor wrote:
> The issue here is that we have a libcall without the REG_EQUAL note.
> That is sensible for a REG_NO_CONFLICT block. Normally gcc will only
> build REG_NO_CONFLICT blocks for code which lower-subreg can't pick
> apart anyhow. Y
On Mon, May 07, 2007 at 10:12:21PM +0200, Paolo Bonzini wrote:
>
> Can you also check -fno-forward-propagate?
With plain -O2, insn 61 disappears in the fwprop1 dump. With -O2
-fno-forward-propagate, insn 61 disappears in the gcse1 dump instead.
--
Rask Ingemann Lambertsen
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>
> > I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
> > REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
> > failure. From the first subreg dump:
Paolo Bonzini wrote:
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any case __tls_get_addr is neither pure nor const
rs6000 says it is, I should try doing the same for x86-64 and see what
happens.
See the patches I've posted; with those I can remove
maybe_encapsulat
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
> REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
> failure. From the first subreg dump:
Try this:
Index: gcc/lower-subreg.c
=
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any case __tls_get_addr is neither pure nor const
rs6000 says it is, I should try doing the same for x86-64 and see what
happens.
(and for non-TLS libcalls, we don't have to know because we never make
them dead anyway ;-)
> Here's what it looks like in the jump dump, right before the lower subreg
> pass:
>
> [...]
>
> (insn 63 59 61 3 memcmp.c:81 (clobber (reg:SI 75)) -1 (nil)
> (insn_list:REG_LIBCALL 62 (nil)))
>
> (insn 61 63 62 3 memcmp.c:81 (parallel [
> (set (subreg:HI (reg:SI 75) 0)
>
On 5/8/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> But without libcall notes, we just see a call_insn and a set to a hard
> register, and we have no way to tell that the call_insn is dead and
> can safely be removed.
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any
But without libcall notes, we just see a call_insn and a set to a hard
register, and we have no way to tell that the call_insn is dead and
can safely be removed.
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
Paolo
On 5/8/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>>> Because it's the semantics of libcall sequences. My take is that the
>>> lower subreg pass breaks it in this case.
>
>I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with
> -fno-move-loop-invariants or -fno-split-wide-type
Because it's the semantics of libcall sequences. My take is that the
lower subreg pass breaks it in this case.
I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with
-fno-move-loop-invariants or -fno-split-wide-types.
Can you also check -fno-forward-propagate?
Yes. It'll
On Mon, May 07, 2007 at 09:35:38PM +0200, Eric Botcazou wrote:
> >It isn't until the loop2_done dump that the problem shows up.
> > delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> > 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
> > replac
On Mon, May 07, 2007 at 10:12:21PM +0200, Paolo Bonzini wrote:
> Eric Botcazou wrote:
> >> It isn't until the loop2_done dump that the problem shows up.
> >>delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> >>62 and seeing both the REQ_EQUAL and the REG_RETVAL note and
Eric Botcazou wrote:
It isn't until the loop2_done dump that the problem shows up.
delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
replacing reg 92 with const_int 0, determines that the while l
>It isn't until the loop2_done dump that the problem shows up.
> delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
> replacing reg 92 with const_int 0, determines that the while libcall
> sequen
15 matches
Mail list logo
