On 2/17/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 16, 2006 at 03:46:57PM -0800, James E Wilson wrote:
> > On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> > > I took the liberty to fix the format issue on behalf of Denis. Is this
> > > OK for mainline?
> >
> > Yes, this looks good to me.
On Thu, Feb 16, 2006 at 03:46:57PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> > I took the liberty to fix the format issue on behalf of Denis. Is this
> > OK for mainline?
>
> Yes, this looks good to me.
I checked it in. Here is the testcase.
H.J.
2006-02
On Thu, 2006-02-16 at 14:46, H. J. Lu wrote:
> I took the liberty to fix the format issue on behalf of Denis. Is this
> OK for mainline?
Yes, this looks good to me.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Thu, Feb 16, 2006 at 12:34:19PM -0800, James E Wilson wrote:
> On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> > It's corrected and tested on ia64 and x86-64. I've attached new version.
> > Denis.
>
> This look pretty good. There is still one place where the spacing looks
> funny.
>
> > +
On Thu, 2006-02-16 at 11:59, Denis Nagorny wrote:
> It's corrected and tested on ia64 and x86-64. I've attached new version.
> Denis.
This look pretty good. There is still one place where the spacing looks
funny.
> + if (test >= regno && test < endregno)
> + return 1;
Check
Andrew Pinski wrote:
On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote:
Should
+static int reg_inc_found_and_valid_p (unsigned int, unsigned int, rtx);
be removed if we do this way?
Yes, in fact it does not need to be there in the first place as
the function is declared before the use.
-- Pin
Andrew Pinski wrote:
What about defining the code this way:
#ifdef AUTO_INC_DEC
+ static int
+ reg_inc_found_and_valid_p (unsigned int regno,
+unsigned int endregno,
+rtx insn)
+ {
...
}
#else
#define reg_inc_found_and_valid_p(regno,endre
On Feb 16, 2006, at 3:20 PM, H. J. Lu wrote:
Should
+static int reg_inc_found_and_valid_p (unsigned int, unsigned int,
rtx);
be removed if we do this way?
Yes, in fact it does not need to be there in the first place as
the function is declared before the use.
-- Pinski
On Thu, Feb 16, 2006 at 03:03:02PM -0500, Andrew Pinski wrote:
>
> On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
>
> >James E Wilson wrote:
> >>Yes, that is what I was suggesting.
> >
> >It's corrected and tested on ia64 and x86-64. I've attached new
> >version.
> >Denis.
> >+ /* Return 1 if
On Feb 16, 2006, at 2:59 PM, Denis Nagorny wrote:
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new
version.
Denis.
+ /* Return 1 if registers from REGNO to ENDREGNO are the subjects of a
+REG_INC note in insn INSN
James E Wilson wrote:
Yes, that is what I was suggesting.
It's corrected and tested on ia64 and x86-64. I've attached new version.
Denis.
Index: reload.c
===
*** reload.c(revision 35)
--- reload.c(working copy)
***
On Wed, 2006-02-15 at 05:52, Denis Nagorny wrote:
> Did I understand your idea correctly? Can you comment new patch version.
> It isn't fully tested but am I going in right direction?
Yes, that is what I was suggesting.
In choose_reload_regs, you only need one regno_clobbered_p call, with
sets ==
Jim Wilson wrote:
I don't believe this is safe. If you look at the uses of
regno_clobbered_p in reload.c, the comments clearly indicate that we are
looking for registers used in clobbers. So unconditionally adding code
that handles REG_INC notes will break these uses. You have to add the
RE
On Tue, Feb 14, 2006 at 01:59:21PM -0800, Jim Wilson wrote:
> H. J. Lu wrote:
> >PR rtl-optimization/25603
> >* reload.c (reg_inc_found_and_valid_p): New.
> > (regno_clobbered_p): Handle REG_INC as 25603 workaround.
>
> I don't believe this is safe. If you look at the uses of
H. J. Lu wrote:
PR rtl-optimization/25603
* reload.c (reg_inc_found_and_valid_p): New.
(regno_clobbered_p): Handle REG_INC as 25603 workaround.
I don't believe this is safe. If you look at the uses of
regno_clobbered_p in reload.c, the comments clearly indicate that we
On Tue, Feb 14, 2006 at 11:48:36AM -0800, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >>PR26258: wrong code caused by incorrect alias analyis.
> >
> > This is now fixed on both the branch and the mainline.
>
> Good.
>
> > I guess you meant 26258, the patch for 26029 is by Zdenek and stil
16 matches
Mail list logo
