This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]

Re: INSN_CODE_NUMBER of INT_MAX

To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>, Joern Rennecke <amylaar at redhat dot com>, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org
Subject: Re: INSN_CODE_NUMBER of INT_MAX
From: Jan Hubicka <jh at suse dot cz>
Date: Sat, 28 Jul 2001 21:59:17 +0200
References: <20010727161210.J19763@atrey.karlin.mff.cuni.cz> <200107271831.f6RIVGr02434@phal.cambridge.redhat.com> <20010728201900.A25604@atrey.karlin.mff.cuni.cz> <20010728114219.C29883@redhat.com>

> This is the only sensible thing to do.  The other two options pessimize
> all of the optimizers at the expense of a not-terribly-good register
> allocator.
I am just implementing this.  Additionally we may move libcall regions
notes in case the first insn is dead.

But what to do in case the previous set is present and already contains
some REG_EQUAL note.  Do we have some mechanizm somewhere to decide which
one is more valuable?

Honza
> 
> 
> r~

Follow-Ups:
- Re: INSN_CODE_NUMBER of INT_MAX
  - From: Richard Henderson

References:
- Re: INSN_CODE_NUMBER of INT_MAX
  - From: Jan Hubicka
- Re: INSN_CODE_NUMBER of INT_MAX
  - From: Joern Rennecke
- Re: INSN_CODE_NUMBER of INT_MAX
  - From: Jan Hubicka
- Re: INSN_CODE_NUMBER of INT_MAX
  - From: Richard Henderson

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]