[tree-ssa]: Another SSAPRE update

Committed.
Fixes a few bugs in strength reduction, and keeps the SSA 
representation up to date for strength reduction.
Adds a new TODO item for cleaning up remapping crud, so i don't forget.

I can easily expose a bug in insertion with this change:

Given
int main(void)
{
         int i;
         int a,b,c;
         b = c = 5;
         i = 0;
         a = i * 5;
         for (; i < 50; i++)
         {
                 a = i * 5;

         }
}

This simplifies to:
main()
{
   int i;
   int a;
   int b;
   int c;
   c = 5;

Re: [tree-ssa]: Another SSAPRE update

On Mon, 2002-09-30 at 19:29, Daniel Berlin wrote:

> I can easily expose a bug in insertion with this change:
> 
Heh, insertion code has been reduced to {}.  I still haven't rewritten
it yet, but it looks infinitely easier than before.

> Is this fun type of inconsistency in the new IR, and thus, i should 
> change the insertion routine to do the right thing, or is it gone, and 
> thus, i should just ignore the problem for now, and do something about 
> it when the new simplifier goes in and the insertion routines get 
> updated/rewritten/whatever?
> 
That insanity should be fixed.  I'll be committing the new code soonish 
(after Jason merges in the main patch for GENERIC and GIMPLE into
tree-ssa).

Diego.

Re: PATCH for sibcalls on i386

On Mon, Sep 30, 2002 at 05:07:58PM -0400, John David Anglin wrote:
> I've been looking and I don't have a full explanation yet.  I see in
> expand call that try_tail_call is 0 and try_tail_recursion is 1.  It
> looks like try_tail_call == 1 is necessary for sibcall generation
> (see line 2623 in calls.c).  try_tail_call is 0 because
> FUNCTION_OK_FOR_SIBCALL always is 0 for TARGET_64BIT.  What I don't
> understand is why we get a sibcall on hppa-linux which defines
> FUNCTION_OK_FOR_SIBCALL to be 0.

Do you get a sibcall?  try_tail_recursion does not rely on
the sibcall machinery, and is independent of it.  It should
not be shut off by FUNCTION_OK_FOR_SIBCALL.

r~

Objective-C additions to gcc-3.3/changes.html

I went through the recent ChangeLog, and compiled a list of Objective-C
user-visible changes in GCC 3.3.

Ok to apply ?

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/changes.html,v
retrieving revision 1.7
diff -u -r1.7 changes.html
--- changes.html        23 Aug 2002 04:08:46 -0000      1.7
+++ changes.html        1 Oct 2002 00:13:38 -0000
 <at>  <at>  -119,6 +119,26  <at>  <at> 
         aggregate types. </li>
   </ul>

+<h3>Objective-C</h3>
+
+  <ul>
+    <li>Generate an error if Objective-C objects are passed by value in function and
+         method calls</li>
+    <li>When -Wselector is used, check the whole list of selectors at the
+         end of compilation, and emit a warning if a  <at> selector() is not
+         known</li>
+    <li>Define __NEXT_RUNTIME__ when compiling for the NeXT runtime</li>
+    <li>No longer need to include objc/objc-class.h to compile self calls
+         in class methods (NeXT runtime only)</li>
+    <li>New -Wundeclared-selector option</li>
+    <li>Removed selector bloating which was causing object files to be 10%
+         bigger on average (GNU runtime only)</li>

Re: PATCH for sibcalls on i386

> Do you get a sibcall?  try_tail_recursion does not rely on

No.

> the sibcall machinery, and is independent of it.  It should
> not be shut off by FUNCTION_OK_FOR_SIBCALL.

The main difference between the 32-bit ports (e.g., hppa-linux)
and hppa64-hpux is that calls on hppa64-hpux always pass a pointer
to the first argument on on the stack (arg8) as one of the arguments.
Possibly, this is the reason that there is no sibcall.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH for sibcalls on i386

> > the sibcall machinery, and is independent of it.  It should
> > not be shut off by FUNCTION_OK_FOR_SIBCALL.
> 
> The main difference between the 32-bit ports (e.g., hppa-linux)
> and hppa64-hpux is that calls on hppa64-hpux always pass a pointer
> to the first argument on on the stack (arg8) as one of the arguments.
> Possibly, this is the reason that there is no sibcall.

This appears to be the reason why we don't get recursive tail calls
on hppa64-hpux.  sequence_uses_addressof returns nonzero because
current_function_internal_arg_pointer is found.  This causes
no_sibcalls_this_function to be set.  Thus, I think that all the
sibcall tests need to be xfailed for this target.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

[PATCH/RFA] VAX ELF revisited

On Mon, Jul 15, 2002 at 04:46:29PM -0700, Richard Henderson wrote:

 > On Tue, Jun 25, 2002 at 11:12:04PM -0700, Matt Thomas wrote:
 > > Is there any reason the rest of the VAX ELF changes can't be pulled up?
 > > [After Jason Thorpe and I merge our respective diffs.]
 > 
 > Nope.  Do go ahead and post the pieces separately though.
 > 
 > 
 > r~

Right, so, this merging of respective diffs took a bit longer than I'd
hoped (ahem) .. partially because I'm not paid to hack on the VAX at
my Day Job (don't we all wish we could be , and then partially because
the compiler just plain broken on VAX for a spell (and I just didn't have
the time to dig into why)...

That said... attached are the rest of the changes required to support
ELF on the VAX.  There's nothing really all that new, here, although I
did one small bit of cleanup suggested by Richard, use an unspec_volatile
for the istream-sync (it actually fixes a bug -- before the change, the
istream-sync would sometimes be emitted before the trampoline was finalized).

The last testsuite run I did is here:

	http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00973.html

Since that run, I actually fixed another bug, and I need to run the
testsuite again (that takes a while, though, even cross-compiling on
a reasonably fast Athlon).  I'll post those when available.

Re: [tree-ssa]: Another SSAPRE update

On Monday, September 30, 2002, at 07:48  PM, Diego Novillo wrote:

> On Mon, 2002-09-30 at 19:29, Daniel Berlin wrote:
> That insanity should be fixed.  I'll be committing the new code soonish
> (after Jason merges in the main patch for GENERIC and GIMPLE into
> tree-ssa).

Okeydokey, i'll just ignore the bug for now then.
Got to finish fixing strength reduction updating anyway, before someone 
notices it's buggy (it'll set reaching defs wrong when you have 
multiple injuries, because i process them in the reverse order i 
should).
:P

>
> Diego.
>

Re: [PATCH/RFA] VAX ELF revisited

On Mon, Sep 30, 2002 at 09:10:19PM -0700, Jason R Thorpe wrote:

 > Here's the ChangeLog entry.

...Grr, and now here's the diffs.

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Index: config.gcc
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.250
diff -c -r1.250 config.gcc
*** config.gcc	26 Sep 2002 10:42:04 -0000	1.250
--- config.gcc	1 Oct 2002 03:38:26 -0000
***************
*** 2609,2615 ****
  	xm_defines=POSIX
  	;;
  vax-*-netbsdelf*)
! 	echo "GCC does not yet support the ${machine} target"; exit 1
  	;;
  vax-*-netbsd*)
  	tm_file="${tm_file} netbsd.h netbsd-aout.h vax/netbsd.h"
--- 2609,2616 ----
  	xm_defines=POSIX
  	;;
  vax-*-netbsdelf*)

[RFC] potential fix for PR middle-end/7151

I know the sparc bits below are OK, but I want some eyes on
the reload bits please.  A full sparc-linux regression run passed with
these changes, and I'm running a sparc64-linux one now.

What happens is that SUBREG's are not handled for the
SECONDARY_MEMORY_NEEDED cases in gen_reload() so we abort when trying
to generate a reload for:

	(set (reg:SI INTEGER_REGNO) (subreg:SI (reg:DI FLOAT_REGNO) 0))

which has to be done via secondary memory on Sparc.

I argue the reload change to be correct, because when this case is
triggered it currently just goes "emit (set OUT IN)" which is
guarenteed to abort.

I do not argue that the reload fix is complete.  Here is why.

I tried to verify that other parts of reload handle SUBREGs properly
as well.  In reload.c:push_reload() there is all of this logic about
emitting two reloads for a subreg.  This occurs when
reload_inner_reg_of_subreg() returns true.  In this case, the toplevel
SUBREG reload won't get checked by the SECONDARY_MEMORY_NEEDED check
because we will preserve the SUBREG and that check only accepts REG.

So, shouldn't these two SECONDARY_MEMORY_NEEDED checks in
push_reload() have similar logic to what I'm adding here to
reload1.c:gen_reload() ?