From: David Edelsohn <dje@watson.ibm.com>
To: egcs@cygnus.com
Subject: Re: Problems on PowerPC...
Date: Thu, 21 Aug 1997 16:51:55 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
In-Reply-To: Pine.NEB.3.96.970821122212.26124I-100000@water.waterw.com
>>>>> David McWherter writes:
David> I dunno if they're C++ constructors, but a function pointer from
David> __CTOR_LIST__ is being picked off and run by __do_global_ctors_aux() when
David> I compile with egcs. When I compile genattr with my standard gcc, it
David> doesn't do so. The egcs-compiled genattr dies because the pointer it
David> picks out from __CTOR_LIST__ is a pointer to a block of illegal
David> instructions, and a SIGILL is generated.
David> I dunno. My standard-gcc-built code seems to have empty __CTOR_LIST__'s,
David> but the egcs stuff has something there.
All of the various Linux for PowerPC use SVR4 which has init and
fini object file sections. Something is ending up in the __CTOR_LIST__
when using egcs that should not be present (genattr and obstack.o are pure
C, not C++: no constructors exist). I would assume that something in the
rs6000/sysv4.h configuration distributed in the pax files on linuxppc.org
has not made it back to the FSF sources on which egcs is based.
David
WARNING: multiple messages have this Message-ID
From: Bernd Schmidt <crux@Pool.Informatik.RWTH-Aachen.DE>
To: egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Thu, 21 Aug 1997 17:37:12 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821173712.eGfuXft0r_s3L2WmXRRwFEECAzVKWgdnj2IziXZamwE@z> (raw)
In-Reply-To: 199708211632.RAA01567@phal.cygnus.co.uk
> You are right, I mixed up something here. What I actually saw was when
> an inherit was missed, the new reload - or its secondary reloads -
> would clobber other reload registers, which could otherwise have been used
> for subsequent inherits.
> reload_cse coudn't clean up the mess - it just changed the reload for the
> missed inherit from a memory-register to a register-register move.
> It isn't clever enough to reassign reload registers and then reclaim the
> freed register for further cse.
There are a zillion variations of this kind of problem. The following
code, or something that looks similar, is generated rather frequently:
movl 16(%esp),%eax
movl (%eax),%eax
movl 16(%esp),%edx
Another problem was mentioned today: the compiler really should move
constants that are used multiple times into registers if possible. These
problems are similar, maybe they can be addressed together. Again, I
think reload_cse_regs might be the right place to add cleverness about this.
I'll send some initial patches tomorrow or so.
Bernd
WARNING: multiple messages have this Message-ID
From: Dave Love <d.love@dl.ac.uk>
To: egcs@cygnus.com
Subject: g77 building [was Re: bootstrapping problems with native compiler]
Date: Thu, 21 Aug 1997 17:37:23 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821173723.pQ1Uhx-JqUZpfNPUzt3jCyYwb3fbDrX_OfV2NtEfP8o@z> (raw)
In-Reply-To: Mon, 18 Aug 1997 16:56:55 -0700"
>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
Jim> The released G77 is known basically to survive criss-cross builds.
Jim> (The sprintf test makes a pessimistic assumption if necessary.)
Jim> But it does so by making guesses if CC is a cross compiler that
Jim> can't link. This would not be necessary if the f77-runtime was
Jim> a separate directory from the compiler directory.
I'm sure I understand this properly and haven't had time to revisit
it. I won't be able to until at least the back end of next week. I
probably need to scrutinize cross-gcc etc. again, which I haven't
looked at for some time. The G77 configuration does assume that it
has a working C compiler/library built for the host and target before
it starts and I'm not sure how else it can work. (I'd have thought it
would be the same for ObjC too.) However, g77 may well not be doing
the Right Thing because it's been out on a limb with no useful model.
I trust we can sort out any problems that there are later on.
I'm afraid I don't understand the current build system and I don't
know whether it's broken the g77 configuration/build (which has
changed somewhat recently anyhow). I guess if it's problematic at
present, people have to take f77 out of LANGUAGES.
If the configuration is going to be changed, it would probably be a
good idea to discuss plans with fortran@gnu.ai.mit.edu, especially as
there are other things that we may want to do in the future, such as
using Fortran source directly in the runtime.
WARNING: multiple messages have this Message-ID
From: Dave Love <d.love@dl.ac.uk>
To: egcs@cygnus.com
Subject: Re: fixing the c++/f77 circular dependency
Date: Thu, 21 Aug 1997 17:43:07 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821174307.XGuiv8dbBy09EvSn16Wvja_bL7_jwAgsTgYQRxHksN8@z> (raw)
In-Reply-To: Wed, 20 Aug 1997 15:18:31 -0700"
>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
Jim> The fourth option is easy to implement. The only downside I can see is
Jim> that the f77-runtime is now configured always,
It shoudn't be, and I didn't think it was in the vanilla version.
Will try to look at it before absconding for the holiday weekend.
WARNING: multiple messages have this Message-ID
From: Jeffrey A Law <law@hurl.cygnus.com>
To: egcs@cygnus.com
Subject: Re: Some Haifa scheduler bugs
Date: Thu, 21 Aug 1997 17:43:59 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821174359.3C4vx1IEPNYc4zTg34B7zbSXpsTfEM9lEyr2qu4vpC0@z> (raw)
In-Reply-To: Some Haifa scheduler bugs
In message <Pine.SOL.3.90.970821173718.733B-100000@maigret.informatik.rwth-aa
chen.de>you write:
> I've thought about something like this, but this code won't work, I think.
> It will call reemit_notes twice for the last insn in the SCHED_GROUP and
> not at all for the first one. I've tried thinking of ways to use just one
> loop, but they all had problems with putting all notes in the right places.
Good point. However, the more I look at that SCHED_GROUP_P loop,
the more I think it must be broken.
Consider if we have Z <-A <-B <-C, all with SCHED_GROUP_P set on A B & C,
but not Z.
insn = C
We start the while loop (SCHED_GROUP_P (A) == 1)
prev = B
move_insn1 (C, last)
insn = B
2nd iteration (SCHED_GROUP_P (B) == 1)
prev = A
move_insn1 (B, last)
insn = A
3rd iteration (SCHED_GROUP_P (A) == 1)
prev = Z
move_insn_1 (A, last)
insn = Z
loop terminates (SCHED_GROUP_P (Z) == 0)
move_insn1 (Z, last)
So we end up moving one insn more than we should right?
Seems to me move_insn should look like this:
static rtx
move_insn (insn, last)
rtx insn, last;
{
while (SCHED_GROUP_P (PREV_INSN (insn)))
{
rtx prev = PREV_INSN (insn);
move_insn1 (insn, last);
reemit_notes (insn, insn);
insn = prev;
}
move_insn1 (insn, last);
return reemit_notes (insn, insn);
}
Can you try it? Or give me the testcase that's currently failing
for you so that I can try it myself?
Jeff
WARNING: multiple messages have this Message-ID
From: Dave Love <d.love@dl.ac.uk>
To: egcs@cygnus.com
Subject: Re: fixing the c++/f77 circular dependency
Date: Thu, 21 Aug 1997 17:47:23 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821174723.Sk8orNWE-8gjP7J9AoybR_e0xsfCHOd0cvjY8HAAhd0@z> (raw)
In-Reply-To: Wed, 20 Aug 1997 16:19:35 -0700"
>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:
Doug> You could add a --enable-lang=foo [or some such] option,
Doug> so while LANGUAGES=x is gone, the ability to only build a few
Doug> is not.
I'd vote for that sort of thing.
WARNING: multiple messages have this Message-ID
From: Dave Love <d.love@dl.ac.uk>
To: egcs@cygnus.com
Subject: Re: mdbench for g77 & f2c+gcc
Date: Thu, 21 Aug 1997 18:32:49 -0000 [thread overview]
Message-ID: <9708211648.AA22436@rios1.watson.ibm.com> (raw)
Message-ID: <19970821183249.S7A2zGdOlJ4JUOZgtUF5Ho1IQkIbhLYUeLBl8gTZJpo@z> (raw)
In-Reply-To: Thu, 21 Aug 1997 00:33:40 -0600"
If mdbnch discussions are continuing, I might point out some things
about it and some possibly-mis-remembered facts I don't have time to
check on. Toon might correct me.
The first thing is that in my experience a couple of years ago it
depends critically on the cache and should probably be run single-user
for compiler benchmarking, as opposed to real-life performance. (I
think this is an intentional feature of mdbnch, but not necessarily
representative.) On MIPS R4000s it made a significant difference when
gcc 2.7 introduced an r4000 configuration and g77 basically caught up
with MIPS f77 on mdbnch IIRC; they've probably both got better since.
It looks as though data in (static) COMMON are a bottleneck (if
-malign-double makes a consistent significant improvement) and that
may hurt optimization -- Craig or Toon can probably say better.
Automatic data in it will be subject to the non-double-alignment
problem on [56]86.
On x86 -fforce-addr often has a significant effect on fortran in
either direction, doubtless differently in different parts of the
code.
f2c-compiled code is normally significantly better with gcc if you use
`-a' (basically equivalent to g77's default -fautomatic), as is always
appropriate for standard-conforming code. Failure to use -a has given
f2c and C-as-UNCOL a worse press than warranted.
Beware that old Fortran benchmarks often have coding problems which
g77 will show up, either through straight standard-non-conformance or
portability problems such as not declaring EXTERNALs; mdbnch did the
latter IIRC, though it just elicits a warning from g77.
[One important x86-performance-related thing that backend experts
might like to look at sometime is why the backend allegedly doesn't
(or didn't early this year) generate optimal 586 code for the level-1
BLAS (O(n) floating point linear algebra), which people have been
feeling the need to code in assembler. I can provide references for
that at some stage if anyone is interested.]
Gratifying interest in Fortran :-).
next reply other threads:[~1997-08-21 16:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-08-21 16:51 David Edelsohn [this message]
1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-21 17:37 ` g77 building [was Re: bootstrapping problems with native compiler] Dave Love
1997-08-21 17:43 ` fixing the c++/f77 circular dependency Dave Love
1997-08-21 17:43 ` Some Haifa scheduler bugs Jeffrey A Law
1997-08-21 17:47 ` fixing the c++/f77 circular dependency Dave Love
1997-08-21 18:32 ` mdbench for g77 & f2c+gcc Dave Love
[not found] <Pine.NEB.3.96.970821084635.26124B-100000@water.waterw.com>
1997-10-20 13:24 ` Problems on PowerPC Jeffrey A Law
-- strict thread matches above, loose matches on Subject: below --
1997-08-28 21:13 Michael Meissner
1997-08-22 19:47 H.J. Lu
1997-08-22 19:47 dtm
1997-08-21 21:20 dtm
1997-08-21 9:21 David McWherter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9708211648.AA22436@rios1.watson.ibm.com \
--to=dje@watson.ibm.com \
--cc=egcs@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).