This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: INSN_CODE_NUMBER of INT_MAX
- To: Richard Henderson <rth at redhat dot com>, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org, jh at suse dot cz
- Subject: Re: INSN_CODE_NUMBER of INT_MAX
- From: Jan Hubicka <jh at suse dot cz>
- Date: Thu, 26 Jul 2001 22:21:06 +0200
- References: <10107262014.AA11402@vlsi1.ultra.nyu.edu> <20010726131508.E20704@redhat.com>
> On Thu, Jul 26, 2001 at 04:14:57PM -0400, Richard Kenner wrote:
> > OK, then I see the bug. delete_noop_moves doesn't delete a nop insn that
> > has a REG_EQUAL note. But such can *still* get the INT_MAX INSN_CODE.
> > Indeed ths insn in question had that note.
> >
> > I'm not sure what was intended here.
>
> I think this was due to some libcall lossage. Probably it shouldn't
> be checking for REG_EQUAL but REG_RETVAL.
The comment claims that the REG_EQUAL on noop move may be usefull later.
I don't think so (especially at combine time) so I suggest to blast that code.
The REG_RETVAL issue looks important. We currently remove the insns
with REG_LIBCALL note, so the patching out REG_RETVAL should work too.
I don't think we commonly elliminate libcall regions after combine.
>
> To be sure, INT_MAX should always be deleted. (Jan, I thought I
> mentioned having a manifest constant NOOP_MOVE_INSN_CODE here?)
Yes, I am having patch for that at home. I will come with it tommorow.
(I also do have fix for print_rtl abort).
Honza
>
>
> r~