i370 port

i370 port

[Paul Edwards]

Hello GCC maintainers.

There used to be an i370 target for GCC.  It was written in 1989,
and put into GCC 2.5 in 1993.

It has always been semi-working, but never good enough to
actually use.

It was dropped from GCC 4 when there was supposedly no
maintainer available.  Actually, Dave Pitts and myself were
both maintaining it at that time, but we were both still working
on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
last time it was included in the normal GCC distribution.

We were both maintaining it, and continue to maintain it,
because MVS doesn't have any alternate free C compiler
available.

As of yesterday, after years of work, an i370 version was 
released that is now fully working.  The code generator has 
no known bugs that would stop it from being C90-compliant,
and GCC can fully regenerate itself, with full optimization.  

You can see it here:

http://gccmvs.sourceforge.net

It's based on GCC 3.2.3.

There is also a free i370 emulator (Hercules) and a free i370-based 
operating system (MVS/380) that enables the compiler to be fully 
tested and fully regenerate itself on its native environment.  Not
only that, but there is an effort underway to allow this free
environment to be made available on the internet so that Unix
users can do an MVS build (takes around 4 hours if done properly
- ie 3 stage, full optimization, on an emulated machine), from the 
safety of their Unix box.

Both of those products are also under active development by a
community of mainframe enthusiasts.

In addition, that code has been ported to GCC 3.4.6, which is now
working as a cross-compiler at least.  It's still some months away
from working natively though.  It takes a lot of effort to convert
the Posix-expecting GCC compiler into C90 compliance.  This has
been done though, in a way that has minimal code changes to the
GCC mainline.

There is a lot of other activity (e.g. availability of REXX, PL/1, Cobol)
that rests on the C compiler being available.

So, my question is - what is required to get the i370 port reinstated
into the GCC mainline?

Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
HLASM, isn't 370, isn't C90, isn't MVS.  It may well be possible to
change all those things, and I suspect that in a few years from now
I may be sending another message asking what I need to do to get 
all my changes to the s390 target into the s390 target.  At that time,
I suspect there will be a lot of objection to "polluting" the s390 target
with all those "unnecessary" things.

So, here's hoping that the i370 port can end up where it was originally
intended to end up, and that all the effort that was spent in the GCC
mainline to get rid of the ASCII assumptions can now be put to good
use.

BFN.  Paul.

Re: i370 port

[Joseph S. Myers]

On Fri, 5 Jun 2009, Paul Edwards wrote:

> It was dropped from GCC 4 when there was supposedly no
> maintainer available.  Actually, Dave Pitts and myself were
> both maintaining it at that time, but we were both still working
> on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
> last time it was included in the normal GCC distribution.

(For reference, the port was removed in SVN revision 77216; before then it 
had had various largely mechanical changes as part of changes to multiple 
back ends or target-independent code, with r69086 as the last vaguely 
i370-only change but no changes appearing to come from someone 
specifically working and testing on i370 for some years before then.  "svn 
log svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i370@77215" shows the 
history.)

> We were both maintaining it, and continue to maintain it,
> because MVS doesn't have any alternate free C compiler
> available.

To merge back into FSF GCC, the people who have made changes that would be 
merged back will need to have copyright assignments on file at the FSF 
(and disclaimers from any relevant employers).  I don't have a current 
copy of the assignments list (my very old copy does show assignments from 
David G. Pitts with an employer disclaimer dating from 1993).

> So, my question is - what is required to get the i370 port reinstated
> into the GCC mainline?

The basic requirements for a resurrected port are the same as for a new 
port; it needs to be assigned to the FSF, to pass the normal technical 
review, and the SC needs to approve someone as a maintainer of the port 
(there may be a bottleneck with the last stage, since there are currently 
at least three new ports pending approval).  It is a very good idea if you 
can run the testsuite for the port and will be posting results to 
gcc-testresults regularly.

I would encourage going through all the changes made to the i370 port on 
GCC mainline, after 3.1/3.2 branched and before the port was removed, to 
see what should be merged into your version for mainline; ultimately it 
would be up to you how you get it updated for all the mechanical changes 
on mainline since 3.2, but those changes (see command above to get logs) 
may be a useful guide to how to do some of the updates.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port

[Paul Edwards]

>> We were both maintaining it, and continue to maintain it,
>> because MVS doesn't have any alternate free C compiler
>> available.
>
> To merge back into FSF GCC, the people who have made changes that would be
> merged back will need to have copyright assignments on file at the FSF
> (and disclaimers from any relevant employers).  I don't have a current
> copy of the assignments list (my very old copy does show assignments from
> David G. Pitts with an employer disclaimer dating from 1993).

There's only 3 people who have made changes.  Dave Pitts, Linas
Vepstas and myself.  Dave you already have apparently.  Linas's
code is largely already merged - just his last set of changes didn't
get put in.  That leaves me.  I work as a contractor and I'd probably
be sacked if I tried to either bring in or attempt to maintain gcc.
All my work was done at home.

>> So, my question is - what is required to get the i370 port reinstated
>> into the GCC mainline?
>
> The basic requirements for a resurrected port are the same as for a new
> port; it needs to be assigned to the FSF, to pass the normal technical
> review, and the SC needs to approve someone as a maintainer of the port
> (there may be a bottleneck with the last stage, since there are currently
> at least three new ports pending approval).  It is a very good idea if you
> can run the testsuite for the port and will be posting results to
> gcc-testresults regularly.

The port is to a pure C90 environment (ie not posix, not unix).  It was a
major effort to achieve that, and it has only just been completed to the
point where the compiler recompiles itself with full optimization.  The
environment where it runs is not set up to run shell scripts or makes
or test suites.  It's set up to run JCL, and there's a stack of JCL card
decks to allow GCC to compile, which would be good to have included
in the i370 directory.

It's difficult enough just to get GCC to know to open dd:include(xxx)
for an include of "xxx.h" and dd:sysincl(xxx) for an include of <xxx.h>.
That logic was revamped in gcc 3.4.6 so I haven't put it in yet.  It'll
probably be months before I do that, because I can't test it until it
gets up onto the mainframe.  And once again, in preparation for that,
I need to make it a pure C90 application.  So that is where I spend
my effort.

Note that the i370 port used to be in GCC even though it was riddled
with bugs.  It took literally years to get rid of them.  I would have
thought that GCC recompiling itself was a damn good start for
inclusion, irrespective of any test suites (assuming those test
suites are even C90 code - as they would need to be to work).

> I would encourage going through all the changes made to the i370 port on
> GCC mainline, after 3.1/3.2 branched and before the port was removed, to
> see what should be merged into your version for mainline; ultimately it
> would be up to you how you get it updated for all the mechanical changes
> on mainline since 3.2, but those changes (see command above to get logs)
> may be a useful guide to how to do some of the updates.

I have already merged the changes made from 3.2.3 to 3.4.6 into my
code, and have a diff against 3.4.6 available already.  ie, that covers
all known code changes.  But it only works as a cross-compiler at the
moment.  It's probably a few months away from being native.

BFN.  Paul.

Re: i370 port

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> The port is to a pure C90 environment (ie not posix, not unix).  It was a
> major effort to achieve that, and it has only just been completed to the
> point where the compiler recompiles itself with full optimization.  The
> environment where it runs is not set up to run shell scripts or makes
> or test suites.  It's set up to run JCL, and there's a stack of JCL card
> decks to allow GCC to compile, which would be good to have included
> in the i370 directory.

You can test a cross compiler if you have some way of copying a test 
executable to the i370 system, running it and getting its output and exit 
status back (actually you don't need to be able to get the exit status 
since DejaGnu has wrappers to include it in the output if needed).  There 
is no need for the target to be able to run shell scripts or makes.  You 
would need to write your own DejaGnu board file that deals with copying 
to/from the i370 system and running programs there.  The testsuite 
routinely runs for much more limited embedded systems (using appropriate 
board files).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> In addition, that code has been ported to GCC 3.4.6, which is now
> working as a cross-compiler at least.  It's still some months away
> from working natively though.  It takes a lot of effort to convert
> the Posix-expecting GCC compiler into C90 compliance.  This has
> been done though, in a way that has minimal code changes to the
> GCC mainline.

You're referring to building GCC for a non-Posix *host*, right?
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?

> Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
> HLASM, isn't 370, isn't C90, isn't MVS.  It may well be possible to
> change all those things, and I suspect that in a few years from now
> I may be sending another message asking what I need to do to get 
> all my changes to the s390 target into the s390 target.  At that time,
> I suspect there will be a lot of objection to "polluting" the s390 target
> with all those "unnecessary" things.

Actually, I would really like to see the s390 target optionally support
the MVS ABI and HLASM assembler format, so I wouldn't have any objection
to patches that add these features ...

I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more.   If there are other problems related to MVS host
support, I suppose those would need to be fixed in common code anyway,
no matter whether the s390 or i370 back-ends are used.

The only point in your list I'm sceptical about is 370 architecture
support -- I don't quite see why this is still useful today (the s390
port does require at a minimum a S/390 G2 with the branch relative
instructions ... but those have been around for nearly 15 years).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> The port is to a pure C90 environment (ie not posix, not unix).  It was a
>> major effort to achieve that, and it has only just been completed to the
>> point where the compiler recompiles itself with full optimization.  The
>> environment where it runs is not set up to run shell scripts or makes
>> or test suites.  It's set up to run JCL, and there's a stack of JCL card
>> decks to allow GCC to compile, which would be good to have included
>> in the i370 directory.
> 
> You can test a cross compiler if you have some way of copying a test 
> executable to the i370 system

It doesn't build executables either.

Only the "-S" option is used.

With that restriction, GCC merely reads a bunch of text files and
writes a text file, and thus is amenable to being a pure C90
application.  That's how it manages to work at all.

> running it and getting its output and exit 
> status back (actually you don't need to be able to get the exit status 
> since DejaGnu has wrappers to include it in the output if needed).  

It so happens that MVS/380 has the ability to be run in batch, and
extracting the exit code won't be a problem either.

Note however that I normally do all my GCC work in Windows,
and the batch running etc is done with batch files.

> There 
> is no need for the target to be able to run shell scripts or makes.  You 
> would need to write your own DejaGnu board file that deals with copying 
> to/from the i370 system and running programs there.  The testsuite 
> routinely runs for much more limited embedded systems (using appropriate 
> board files).

I have a large backlog of work to do with the i370 port already, starting
with getting gcc 3.4.6 running natively.  Isn't that a more productive
thing to do?  Even after 3.4.6 is done, so that every scrap of code is
available, then there's version 4 to do!

BFN.  Paul.

Re: i370 port

[Paul Edwards]

Wow, what a lot of responses.  Last time I tried making
contact, I didn't get a single response!

>> In addition, that code has been ported to GCC 3.4.6, which is now
>> working as a cross-compiler at least.  It's still some months away
>> from working natively though.  It takes a lot of effort to convert
>> the Posix-expecting GCC compiler into C90 compliance.  This has
>> been done though, in a way that has minimal code changes to the
>> GCC mainline.
>
> You're referring to building GCC for a non-Posix *host*, right?

Yep.

> I assume those changes are not (primarily) in the back-end, but
> throughout GCC common code?

Yes.  Or rather, they would be, if it weren't for sleight-of-hand to
minimize that.  I dummied up all the Posix calls to point back to
C90 functions.

Please take a look at the actual changes to GCC.  There's not
a lot:

Here's the exact file:

https://sourceforge.net/project/downloading.php?group_id=195127&filename=gccmvs-3_2_3-7_0.zip&a=50206324

Most of the size is generated code from the md, or other new files,
and not changes to GCC proper.

However, in fact, GCC is turned on its head.  It's a single executable.
C90 doesn't guarantee, and the host doesn't support, the ability to do
a fork() and exec().

>> Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
>> HLASM, isn't 370, isn't C90, isn't MVS.  It may well be possible to
>> change all those things, and I suspect that in a few years from now
>> I may be sending another message asking what I need to do to get
>> all my changes to the s390 target into the s390 target.  At that time,
>> I suspect there will be a lot of objection to "polluting" the s390 target
>> with all those "unnecessary" things.
>
> Actually, I would really like to see the s390 target optionally support
> the MVS ABI and HLASM assembler format, so I wouldn't have any objection
> to patches that add these features ...

Great.

> I understand current GCC supports various source and target character
> sets a lot better out of the box, so it may be EBCDIC isn't even an
> issue any more.

It looks that way from what I've seen of 3.4.6 so far.  However, I
won't know for sure until it's on the host and self-generating.

> If there are other problems related to MVS host
> support, I suppose those would need to be fixed in common code anyway,
> no matter whether the s390 or i370 back-ends are used.

Well, I would like to see that - I don't know why there are all
those calls to open() instead of fopen() etc in the first place,
but I don't see that happening.

> The only point in your list I'm sceptical about is 370 architecture
> support -- I don't quite see why this is still useful today (the s390
> port does require at a minimum a S/390 G2 with the branch relative
> instructions ... but those have been around for nearly 15 years).

The last free MVS was MVS 3.8j which runs on the S/370 architecture.
If you want to write MVS software, for free, your only option is to
pick that up.  It doesn't run on S/390 hardware.

However.  :-)

That's where MVS/380 comes in.

http://mvs380.sourceforge.net

So yes, we can sort of cope with S/390 instructions.  It's just not as
widely supported as the proper S/370 (emulated) machine.  Or rather,
I think we can.  It's into unchartered territory what restrictions
S/380 actually has in its current form.  It's known that it's enough to
run 31-bit GCC using 20 MB of memory though.  Which again, is a
damn good start.

BFN.  Paul.

Re: i370 port

[Joseph S. Myers]

On Fri, 5 Jun 2009, Ulrich Weigand wrote:

> I understand current GCC supports various source and target character
> sets a lot better out of the box, so it may be EBCDIC isn't even an
> issue any more.   If there are other problems related to MVS host

I think the EBCDIC support is largely theoretical and not tested on any 
actual EBCDIC host (or target).  cpplib knows the character set name 
UTF-EBCDIC, but whenever it does anything internally that involves the 
encoding of its internal character set it uses UTF-8 rules (which is not 
something valid to do with UTF-EBCDIC).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> > There is no need for the target to be able to run shell scripts or makes.
> > You would need to write your own DejaGnu board file that deals with copying
> > to/from the i370 system and running programs there.  The testsuite routinely
> > runs for much more limited embedded systems (using appropriate board files).
> 
> I have a large backlog of work to do with the i370 port already, starting
> with getting gcc 3.4.6 running natively.  Isn't that a more productive
> thing to do?  Even after 3.4.6 is done, so that every scrap of code is
> available, then there's version 4 to do!

It's up to you what priorities you assign to different things involved in 
getting this on mainline, but we use test results postings as evidence of 
what sort of state each port is in, where a particular test failure is 
appearing and whether each port is being used, so there may be reluctance 
to accept a port that will not have test results posted regularly for 
mainline.  (This is much less of a problem for OS ports than for CPU 
ports; if one OS for a given CPU has results routinely posted, it doesn't 
matter so much if other OSes don't, though having results for different 
OSes is still useful.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port

[Daniel Jacobowitz]

On Sat, Jun 06, 2009 at 01:39:07AM +1000, Paul Edwards wrote:
>> I understand current GCC supports various source and target character
>> sets a lot better out of the box, so it may be EBCDIC isn't even an
>> issue any more.
>
> It looks that way from what I've seen of 3.4.6 so far.  However, I
> won't know for sure until it's on the host and self-generating.

Why are you migrating to 3.4.6 now, instead of to a current version?
If you want to include this in mainline some day, then eventually it
has to be caught up - and 3.4.6 is older than it may appear from the
release date, since it branched off of mainline five years ago.  A lot
has changed since then.

-- 
Daniel Jacobowitz
CodeSourcery

Re: i370 port

[Paul Edwards]

>> I understand current GCC supports various source and target character
>> sets a lot better out of the box, so it may be EBCDIC isn't even an
>> issue any more.   If there are other problems related to MVS host
>
> I think the EBCDIC support is largely theoretical and not tested on any
> actual EBCDIC host (or target).  cpplib knows the character set name
> UTF-EBCDIC, but whenever it does anything internally that involves the
> encoding of its internal character set it uses UTF-8 rules (which is not
> something valid to do with UTF-EBCDIC).

From the hercules-os380 files section, here's the relevant change
to 3.4.6 to stop it being theoretical:

Index: gccnew/gcc/cppcharset.c
diff -c gccnew/gcc/cppcharset.c:1.1.1.1 gccnew/gcc/cppcharset.c:1.6
*** gccnew/gcc/cppcharset.c:1.1.1.1 Wed Apr 15 16:26:16 2009
--- gccnew/gcc/cppcharset.c Wed May 13 11:07:08 2009
***************
*** 23,28 ****
--- 23,30 ----
  #include "cpplib.h"
  #include "cpphash.h"
  #include "cppucnid.h"
+ #include "coretypes.h"
+ #include "tm.h"

  /* Character set handling for C-family languages.

***************
*** 529,534 ****
--- 531,561 ----
    return conversion_loop (one_utf32_to_utf8, cd, from, flen, to);
  }

+ #ifdef MAP_OUTCHAR
+ /* convert ASCII to EBCDIC */
+ static bool
+ convert_asc_ebc (iconv_t cd ATTRIBUTE_UNUSED,
+          const uchar *from, size_t flen, struct _cpp_strbuf *to)
+ {
+   size_t x;
+   int c;
+
+   if (to->len + flen > to->asize)
+     {
+       to->asize = to->len + flen;
+       to->text = xrealloc (to->text, to->asize);
+     }
+   for (x = 0; x < flen; x++)
+     {
+       c = from[x];
+       c = MAP_OUTCHAR(c);
+       to->text[to->len + x] = c;
+     }
+   to->len += flen;
+   return true;
+ }
+ #endif
+
  /* Identity conversion, used when we have no alternative.  */
  static bool
  convert_no_conversion (iconv_t cd ATTRIBUTE_UNUSED,
***************
*** 606,611 ****
--- 633,641 ----
    { "UTF-32BE/UTF-8", convert_utf32_utf8, (iconv_t)1 },
    { "UTF-16LE/UTF-8", convert_utf16_utf8, (iconv_t)0 },
    { "UTF-16BE/UTF-8", convert_utf16_utf8, (iconv_t)1 },
+ #if defined(TARGET_EBCDIC)
+   { "UTF-8/UTF-EBCDIC", convert_asc_ebc, (iconv_t)0 },
+ #endif
  };

  /* Subroutine of cpp_init_iconv: initialize and return a
***************
*** 683,688 ****
--- 713,722 ----

    bool be = CPP_OPTION (pfile, bytes_big_endian);

+ #if defined(TARGET_EBCDIC)
+   ncset = "UTF-EBCDIC";
+   wcset = "UTF-EBCDIC";
+ #else
    if (CPP_OPTION (pfile, wchar_precision) >= 32)
      default_wcset = be ? "UTF-32BE" : "UTF-32LE";
    else if (CPP_OPTION (pfile, wchar_precision) >= 16)
***************
*** 696,701 ****
--- 730,736 ----
      ncset = SOURCE_CHARSET;
    if (!wcset)
      wcset = default_wcset;
+ #endif

    pfile->narrow_cset_desc = init_iconv_desc (pfile, ncset, 
SOURCE_CHARSET);
    pfile->wide_cset_desc = init_iconv_desc (pfile, wcset, SOURCE_CHARSET);


The generated code appears to be fine from visual inspection.

BFN.  Paul.

Re: i370 port

[Paul Edwards]

>>> I understand current GCC supports various source and target character
>>> sets a lot better out of the box, so it may be EBCDIC isn't even an
>>> issue any more.
>>
>> It looks that way from what I've seen of 3.4.6 so far.  However, I
>> won't know for sure until it's on the host and self-generating.
> 
> Why are you migrating to 3.4.6 now, instead of to a current version?
> If you want to include this in mainline some day, then eventually it
> has to be caught up - and 3.4.6 is older than it may appear from the
> release date, since it branched off of mainline five years ago.  A lot
> has changed since then.

3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
need to make sure those changes have been digested, and no code
has been lost, so that I can pick up the final i370 port and move it.

It's less daunting to get 3.4.6 working first.  At least there the target
actually exists and does obstensibly appear to work!

Migrating from 3.4.6 to 4.x is not going to be made any bigger a deal.
It's not like someone else is making incompatible changes to the
i370 port at the same time as me!

BFN.  Paul.

Re: i370 port

[Joseph S. Myers]

On Sat, 6 Jun 2009, Paul Edwards wrote:

> 3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
> need to make sure those changes have been digested, and no code
> has been lost, so that I can pick up the final i370 port and move it.

But there were probably also (mechanical) changes to the port between when 
3.4 branched (long before 3.4.6 was released) and when the port was 
removed from trunk - that's why the last revision before it was removed 
from trunk may be a better starting point.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port

[Paul Edwards]

>> 3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
>> need to make sure those changes have been digested, and no code
>> has been lost, so that I can pick up the final i370 port and move it.
>
> But there were probably also (mechanical) changes to the port between when
> 3.4 branched (long before 3.4.6 was released) and when the port was
> removed from trunk - that's why the last revision before it was removed
> from trunk may be a better starting point.

Ok, I understand now.  So there were some changes, that would
nominally have made it to GCC 4, but were in fact never officially
released, because it was dropped before release.

So, prior to starting a GCC 4 port (ie the changes may not be
desirable for the GCC 3.4.6 port I am currently working on), I
need to get GCC 3.4 as a base, GCC 3.4.6 as one derivative,
and SVN 77215, then do a 3-way diff/merge to obtain the
"nominal GCC 4" changes.

Or perhaps not.

I don't want the 3.4.6 changes at that point, since anything of
value will be covered by SVN 77215.  So I need to use GCC 3.4.6
as the base, my personal version as one derivative, SVN 77215
as the second derivative, and feed that into the 3-way diff.

Ok, I'll do that when I'm in a position to do the GCC 4 port
attempt.  I'm still months away from completing the GCC 3.4.6
port, and there are other MVS-related projects that are more
important than what is basically a transparent 3.2.3 to 4
upgrade that will only start being useful when it enables something
else to happen (such as the PL/1 front-end).

So I'll be working on that stable 3.4.6 before taking my chances
with what is basically an axed beta (SVN 77215), with still no
indication of whether even a perfectly working self-compiling
i370 target will be accepted unless the testsuite is working first
(and even if it was working, that still may not be enough - as
the next hoop may be an s390 merge - and a requirement to
switch from 370 to 390).

BFN.  Paul.

Re: i370 port

[Paul Edwards]

> Why are you migrating to 3.4.6 now, instead of to a current version?
> If you want to include this in mainline some day, then eventually it
> has to be caught up - and 3.4.6 is older than it may appear from the
> release date, since it branched off of mainline five years ago.  A lot
> has changed since then.

A question about those changes.

One of the things that I experienced when porting 3.2.3 to MVS
was that GCC was sensitive to the exact floating point representation.

Register selection was different depending on those slight differences.

Below is what documentation I have for it.  Dave Edwards, who
wrote another S/370 emulator, was the one who discovered that.

Does anyone know if that was changed somewhere along the line?

BFN.  Paul.



17. The assembler code generated by gccmvs when run on the
PC is slightly different (even when the same parameters
are used for code generation) from that when run on the
mainframe, if -O2 is used instead of -Os. But functionally
equivalent. This non-deterministic nature of the compiler
is disconcerting. It seems to not always allocate registers
consistently. This has been traced to floating point code
in predict.c and local-alloc.c which is sensitive to the
very small changes in floating point representation. This
should be changed to include deltas when comparing floating
point values. Here's an example of what's happening:

*** c-lex.s Mon Jan 14 20:48:35 2008
--- temp.dat Mon Jan 14 21:14:04 2008
***************
*** 1328,1335 ****
           SLR   15,15
           STC   15,0(3,4)
           SLR   6,6
-          LR    9,6
           LR    8,6
           L     2,192(13)
           CLR   2,5
           BNL   L303
--- 1328,1335 ----
           SLR   15,15
           STC   15,0(3,4)
           SLR   6,6
           LR    8,6
+          LR    9,6
           L     2,192(13)
           CLR   2,5
           BNL   L303

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> One of the things that I experienced when porting 3.2.3 to MVS
> was that GCC was sensitive to the exact floating point representation.
> 
> Register selection was different depending on those slight differences.
> 
> Below is what documentation I have for it.  Dave Edwards, who
> wrote another S/370 emulator, was the one who discovered that.
> 
> Does anyone know if that was changed somewhere along the line?
> 
> BFN.  Paul.
> 
> 
> 
> 17. The assembler code generated by gccmvs when run on the
> PC is slightly different (even when the same parameters
> are used for code generation) from that when run on the
> mainframe, if -O2 is used instead of -Os. But functionally
> equivalent. This non-deterministic nature of the compiler
> is disconcerting. It seems to not always allocate registers
> consistently. This has been traced to floating point code
> in predict.c and local-alloc.c which is sensitive to the
> very small changes in floating point representation. This
> should be changed to include deltas when comparing floating
> point values. Here's an example of what's happening:

I agree that GCC output should not depend on details of the host
floating point representation.  (Ideally, the output of GCC built
as a cross-compiler should not depend on the host architecture
at all.)

However, it is hard to say whether such observations made on a
GCC 3.2 code base have any relevance to the current code -- for
example, local-alloc.c does not even exist any more, we now have
a completely new register allocator.

I'd recommend you go ahead with a port to current mainline and
verify whether you still see problems along those lines; if so,
it would be appropriate to open a bug report against GCC.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi guys.

The last class of warning I have from the machine definition is this:

./config/i370/i370.md:784: warning: destination operand 0 allows non-lvalue

which is because I have used r_or_s_operand like this:

;
; movdi instruction pattern(s).
;

(define_insn ""
  [(set (match_operand:DI 0 "r_or_s_operand" "=dm,dS")
        (match_operand:DI 1 "r_or_s_operand" "dm*fF,i"))]
  "TARGET_CHAR_INSTRUCTIONS"
  "*
{
  check_label_emit ();
  if (REG_P (operands[0]))

and I believe what is happening is that r_or_s_operand allows
a constant.

But sometimes r_or_s_operand is being used as a source, in
which case, the constant is fine.  But when it is used as a
destination, it is not fine.

What is the *simplest* way of changing the setup so that the
code generation remains the same, but the warning is eliminated?

Note that this is 3.2.3 and I'm not wanting to restructure the
whole thing to be the same as s390.md.  I am thinking I can
define something like r_or_s_lval_operand which would be
the same as r_or_s_operand except not allow constants.

But wondering if there's something simpler and neater.

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> But sometimes r_or_s_operand is being used as a source, in
> which case, the constant is fine.  But when it is used as a
> destination, it is not fine.
> 
> What is the *simplest* way of changing the setup so that the
> code generation remains the same, but the warning is eliminated?

Well, I guess you need to do two things:

- Define the PREDICATE_CODES macro -- if this is undefined,
  genrecog will consider *any* target-defined predicate as
  potentially allowing non-lvalues, because it cannot know
  better.

- Actually define two distinct predicates, one that allows
  non-lvalue and one that doesn't, and use them as appropriate.

> But wondering if there's something simpler and neater.

Well, you could also simply ignore the warning -- nothing
is going to go wrong because of it.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> But sometimes r_or_s_operand is being used as a source, in
>> which case, the constant is fine.  But when it is used as a
>> destination, it is not fine.
>> 
>> What is the *simplest* way of changing the setup so that the
>> code generation remains the same, but the warning is eliminated?
> 
> Well, I guess you need to do two things:
> 
> - Define the PREDICATE_CODES macro -- if this is undefined,
>  genrecog will consider *any* target-defined predicate as
>  potentially allowing non-lvalues, because it cannot know
>  better.
> 
> - Actually define two distinct predicates, one that allows
>  non-lvalue and one that doesn't, and use them as appropriate.
> 
>> But wondering if there's something simpler and neater.
> 
> Well, you could also simply ignore the warning -- nothing
> is going to go wrong because of it.

Thanks for pointing me in the right direction Ulrich.  Unfortunately
just short of what would have been best for this situation.

I defined the PREDICATE_CODES macro and put in the things
I thought were appropriate:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.33 -r 1.34 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.33
retrieving revision 1.34
diff -r1.33 -r1.34
200a201,204
> #define PREDICATE_CODES \
>   {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
>   {"s_operand", { MEM, CONST_INT }},
>

It had no effect on anything that I could see, but that was to be expected.

I then had a closer look at the machine definitions and realised that some
of them that were defined as r_or_s_operand could instead be
nonimmediate_operand, which started eliminating warnings.

So I proceeded down this track, eliminating things here and there, or
in some cases, opening things up to be more general, with the hope
that I would eventually have things so that the only r_or_s_operand
I needed were ones that didn't require literals, so that I could (at the
end), make this change:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.34 -r 1.35 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.34
retrieving revision 1.35
diff -r1.34 -r1.35
202,203c202,203
<   {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
<   {"s_operand", { MEM, CONST_INT }},
---
>   {"r_or_s_operand", { REG, SUBREG, MEM }}, \
>   {"s_operand", { MEM }},

and something similar in i370.c, to make constants invalid, so that I
could eliminate the warnings.

It took a month to do that, because I kept on being hit by presumed
bugs, which started generating bad or unexpected code when I made
a seemingly innocuous change.  To make matters worse, sometimes
I could only find out whether the code was good or not by running it on
MVS, via the emulator, which means a 2 hour wait for a result.

However, I did get it down to just a handful of warnings, which would
be eliminated now that I could drop the CONST_INT.  And I would
check the generated code to see what I had missed when I took
off the CONST_INT.

Anyway, I took off the CONST_INT, and the warnings all disappeared,
and the code didn't change!

I then found out that even with old versions of the machine definition,
I can have the warning removed by simply not defining CONST_INT
in the PREDICATE_CODES, even though it is allowed when the
function is called.  ie it seems to have no effect on the code
generation, but succeeds in eliminating the warning, and without
needing to define an extra constraint for non-constant situations.

So I've revamped the machine definition unnecessarily.  Well, I
did make things defined more consistently, and did make code
generation improvements, but they're not major, and I wouldn't
have done any of it if I knew I could have just defined a predicate
that wasn't really going to be used.

Oh well.  At the end of the day, the warning has gone, the code
is better and the machine definition is more correct.  :-)

I've also got 3.4.6 working to some extent.  I have managed to
build an single GCC executable, and if I call it with no parameters,
it prints its usage (as designed).

However, if I try to pass parameters it doesn't recognize them.
It could be something to do with not having run the appropriate
stuff through bison (or flex) on an EBCDIC platform.

Normally I use this to get around that problem:

C:\devel\gccnew\gcc>cvs diff -r release-3_4_6 c-parse.c
Index: c-parse.c
===================================================================
RCS file: c:\cvsroot/gccnew/gcc/c-parse.c,v
retrieving revision 1.1.1.1
retrieving revision 1.4
diff -r1.1.1.1 -r1.4
497a498,503
> #if defined(__MVS__) || defined(__CMS__)
> #define YYTRANSLATE(YYX)                      \
>   ((unsigned int) (YYX) <= YYMAXUTOK ? \
>   ((unsigned int) (YYX) < 256 ? yytranslate[_sch_ebcasc[YYX]] \
>   : yytranslate[YYX]) : YYUNDEFTOK)
> #else
499a506
> #endif

But perhaps the new gengtyp lex and yacc, although not used in the
actual GCC executable, are causing a problem by being run on the
ASCII machine.

Next step is to see if I can run the generated files all on MVS so
that that is eliminated from the equation.  Since I actually do have
an EBCDIC flex and bison available now (thanks to 3.2.3).

I also had problems with 3.4.6 when I switched on optimization.
A couple of internal errors popped up, which will presumably
trace back to the i370 code, but be outside my knowledge to
fix.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> I then found out that even with old versions of the machine definition,
> I can have the warning removed by simply not defining CONST_INT
> in the PREDICATE_CODES, even though it is allowed when the
> function is called.  ie it seems to have no effect on the code
> generation, but succeeds in eliminating the warning, and without
> needing to define an extra constraint for non-constant situations.

Actually PREDICATE_CODES does have to match the predicate definitions.
If it does not, you can run into subtle bugs, as the code in genrecog.c
that generates the finite state automaton matching an RTX pattern
against the .md insn definitions *does* make use of PREDICATE_CODES;
for example, it will assume that two predicates with disjoint sets
of PREDICATE_CODES can never both match the same RTX.

This may or may not lead to visible differences when compiling simple
test cases, but I'd expect effects to be visible in more complex
scenarios.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> I then found out that even with old versions of the machine definition,
>> I can have the warning removed by simply not defining CONST_INT
>> in the PREDICATE_CODES, even though it is allowed when the
>> function is called.  ie it seems to have no effect on the code
>> generation, but succeeds in eliminating the warning, and without
>> needing to define an extra constraint for non-constant situations.
>
> Actually PREDICATE_CODES does have to match the predicate definitions.
> If it does not, you can run into subtle bugs, as the code in genrecog.c
> that generates the finite state automaton matching an RTX pattern
> against the .md insn definitions *does* make use of PREDICATE_CODES;
> for example, it will assume that two predicates with disjoint sets
> of PREDICATE_CODES can never both match the same RTX.
>
> This may or may not lead to visible differences when compiling simple
> test cases, but I'd expect effects to be visible in more complex
> scenarios.

Thanks Ulrich.  When I went back to this I found that I had
misdiagnosed - actually the r_or_s didn't allow constants after
all.  It was only const_rtx that it allowed.  So the machine definition
no longer has any warnings and all looks good.

That's with 3.2.3.

With 3.4.6 I have now managed to get an MVS load module,
unoptimized (I already know that optimized doesn't work), to
compile a hello world program successfully, although it abends
at the end of that and I haven't investigated that yet.

So the theoretical EBCDIC support is less theoretical now.
I "needed" to change the parameter search algorithm to stop
being binary search though.

GCC 4 complained (on my Linux system) that I didn't have
various things (gimp etc) installed, which means I would need
that other software to be ported too, which is not a project
I want to work on at the moment.  However, at least it means
that i have successfully merged all the GCCMVS changes
to 3.2.3 in with the (last available) 3.4.6 development, which
was a precursor to any GCC 4 port anyway.  I'll see over time
how GCC 3.4.6 pans out.

Until then, back at GCC 3.2.3, I have a "need" to make the entry
point 0 in my MVS modules.

Currently I generate this:

         COPY  PDPTOP
         CSECT
* X-var bytes
         ENTRY BYTES
* Program data area
         DS    0F
BYTES    EQU   *
         DC    F'258'
* Program text area
LC0      EQU   *
         DC    C'bytes is %d'
         DC    X'15'
         DC    X'0'
         DS    0F
         DC    C'GCCMVS!!'
         EXTRN @@CRT0
         ENTRY @@MAIN
@@MAIN   DS    0H
         USING *,15
         L     15,=V(@@CRT0)
         BR    15
         DROP  15
         LTORG
* X-func main prologue
MAIN     PDPPRLG CINDEX=0,FRAME=96,BASER=12,ENTRY=YES
...
* Function main page table
         DS    0F
PGT0     EQU   *
         DC    A(PG0)
         END   @@MAIN

for a main program.  In order to get the entry point to 0, I need to move 
that
@@MAIN function to the top of the file.

But I only really want that function if this is a main program.  I have 
found
somewhere where I can add some code to see if the function "main" is
being compiled, and set a global variable.

Unfortunately, the place that happens (c-decl) isn't called until after all
the data has been written out!

I looked at the documentation:

http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gccint/Assembler-Format.html#Assembler%20Format

but maybe I'm looking in the wrong place.  Any ideas?

And I have another question - where is the code for __asm__?

Currently that is generating garbage for me:

unsigned int bytes = 258;

__asm__("? :");

int main(void)

BYTES    EQU   *
         DC    F'258'
         o@z
* Program text area

when done in cross-compiler mode, and need to find out where
the literal is being translated (or more likely - failing to be
translated in the first instance).  Any idea where that is?

And final thing - the interest in the __asm__ comes from the hope
that in the generated 370 assembler, it would be possible to have
the C code interspersed to whatever extent possible.  The plan was
to basically somehow get every line of C code, e.g. "int main(void)"
above, and automatically generate an:
__asm__("int main void)");

although I'm not sure what to do about this:

int main(void)
__asm__("? :");
{

which gives a syntax error.  Any idea how to get the mixed
C/assembler when I'm running with the "-S" option and don't
have the luxury of calling the normal "as" which would
normally handle that?

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> GCC 4 complained (on my Linux system) that I didn't have
> various things (gimp etc) installed, which means I would need
> that other software to be ported too, which is not a project
> I want to work on at the moment.  However, at least it means
> that i have successfully merged all the GCCMVS changes
> to 3.2.3 in with the (last available) 3.4.6 development, which
> was a precursor to any GCC 4 port anyway.  I'll see over time
> how GCC 3.4.6 pans out.

This probably is not gimp (the graphics editor) but gmp (the
multi-precision integer operation library) and mpfr (same for
floating-point).  To build any recent GCC you'll indeed need
these two libraries.  Fortunately, they're already available
on s390(x) on Linux, and shouldn't really contain anything
that is OS-specific, so porting those to MVS should hopefully
be straightforward ...

> Until then, back at GCC 3.2.3, I have a "need" to make the entry
> point 0 in my MVS modules.

> Currently I generate this:
[snip]
> for a main program.  In order to get the entry point to 0, I need to move 
> that
> @@MAIN function to the top of the file.

I don't think there is a reliable way to change the sequence of
functions / objects in the output file.

However, it seems to me it shouldn't really be necessary to treat "main"
special.  Usually, the "entry point" isn't really "main", but rather some
function in crt0.o, which then in turn *calls* main after all startup
processing has been done.  As crt0.o can be (and usually is) completely
written in assembler, you can arrange for everything to be in the sequence
that is required.  (On the linker command line, crt0.o would be placed
first, so if the entry point is the first thing in crt0.o it will then
also be the first thing in the executable.)

> And I have another question - where is the code for __asm__?
> 
> Currently that is generating garbage for me:
> 
> unsigned int bytes = 258;
> 
> __asm__("? :");
> 
> int main(void)
> 
> BYTES    EQU   *
>          DC    F'258'
>          o@z
> * Program text area
> 
> when done in cross-compiler mode, and need to find out where
> the literal is being translated (or more likely - failing to be
> translated in the first instance).  Any idea where that is?

Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html


> And final thing - the interest in the __asm__ comes from the hope
> that in the generated 370 assembler, it would be possible to have
> the C code interspersed to whatever extent possible.  The plan was
> to basically somehow get every line of C code, e.g. "int main(void)"
> above, and automatically generate an:
> __asm__("int main void)");

As you note, this doesn't seem workable as the result wouldn't
be syntactically valid ...

> which gives a syntax error.  Any idea how to get the mixed
> C/assembler when I'm running with the "-S" option and don't
> have the luxury of calling the normal "as" which would
> normally handle that?

There doesn't seem to be an easy way to do this from the
compiler.  At the time compiler output is generated, the
original source code text isn't even kept any more; you'd
have to go back and re-read the original source files using
the line-number debug data, just as the assembler would ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> This probably is not gimp (the graphics editor) but gmp (the
> multi-precision integer operation library) and mpfr (same for
> floating-point).  To build any recent GCC you'll indeed need
> these two libraries.  Fortunately, they're already available
> on s390(x) on Linux, and shouldn't really contain anything
> that is OS-specific, so porting those to MVS should hopefully
> be straightforward ...

Ok, thanks Ulrich.

>> Until then, back at GCC 3.2.3, I have a "need" to make the entry
>> point 0 in my MVS modules.
>
>> Currently I generate this:
> [snip]
>> for a main program.  In order to get the entry point to 0, I need to move
>> that
>> @@MAIN function to the top of the file.
>
> I don't think there is a reliable way to change the sequence of
> functions / objects in the output file.

Sorry, my question may not have been clear.

When I see main(), I generate the normal MAIN code, and I don't
care where this goes.

However, given that I now know that a main() exists somewhere
in this source file, I need to change the ASM_FILE_START
output.

I expected that the assembler generation wouldn't happen until
after the optimization was completed, and thus, by then, I
would know whether this was a main.

> However, it seems to me it shouldn't really be necessary to treat "main"
> special.  Usually, the "entry point" isn't really "main", but rather some
> function in crt0.o, which then in turn *calls* main after all startup
> processing has been done.

That is roughly the case, yes.

> As crt0.o can be (and usually is) completely
> written in assembler, you can arrange for everything to be in the sequence
> that is required.  (On the linker command line, crt0.o would be placed
> first, so if the entry point is the first thing in crt0.o it will then
> also be the first thing in the executable.)

Yes, I can do that, but that means I need to have a linker command
line!  The way the MVS linker works, I can link my main program,
(which obviously doesn't have crt0 in it), and, thanks to the "END"
statement, I can specify an entry point.  This means no complaint
from the linker about a default (and wrong) entry point, and no
need for any linker statements.  It all automatically resolves.

It all works really great!

Except - I would ideally like to have an entry point of 0, instead
of the typical "58" or whatever my static variables happen to be.
(my main is normally at the top).

>> And I have another question - where is the code for __asm__?
>>
>> Currently that is generating garbage for me:
>>
>> unsigned int bytes = 258;
>>
>> __asm__("? :");
>>
>> int main(void)
>>
>> BYTES    EQU   *
>>          DC    F'258'
>>          o@z
>> * Program text area
>>
>> when done in cross-compiler mode, and need to find out where
>> the literal is being translated (or more likely - failing to be
>> translated in the first instance).  Any idea where that is?
>
> Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
> http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html

Thanks again!  That didn't seem to make it into 3.4.6.  I was able
to apply most of his stuff to 3.4.6, and I will see how far that gets
me, before trying to find it in 3.2.3.

Or maybe I'll skip it, since the problem doesn't occur on a pure
EBCDIC system.  :-)

>> And final thing - the interest in the __asm__ comes from the hope
>> that in the generated 370 assembler, it would be possible to have
>> the C code interspersed to whatever extent possible.  The plan was
>> to basically somehow get every line of C code, e.g. "int main(void)"
>> above, and automatically generate an:
>> __asm__("int main void)");
>
> As you note, this doesn't seem workable as the result wouldn't
> be syntactically valid ...
>
>> which gives a syntax error.  Any idea how to get the mixed
>> C/assembler when I'm running with the "-S" option and don't
>> have the luxury of calling the normal "as" which would
>> normally handle that?
>
> There doesn't seem to be an easy way to do this from the
> compiler.  At the time compiler output is generated, the
> original source code text isn't even kept any more; you'd
> have to go back and re-read the original source files using
> the line-number debug data, just as the assembler would ...

Ok, well - I would be content with just the source line number
appearing in the output assembler.  Is this information
available as each assembler line is output?

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> I expected that the assembler generation wouldn't happen until
> after the optimization was completed, and thus, by then, I
> would know whether this was a main.

That depends a bit on the compiler version and optimization level,
but (in particular in the 3.x time frame) GCC may output assembler
code on a function-by-function basis, without necessarily reading
in the whole source file first.

As I said, it seems the best way would be to not have care at all
whether or not any particular source file contains a main routine,
but instead do all entry-point processing in the crt0 startup file.

> > As crt0.o can be (and usually is) completely
> > written in assembler, you can arrange for everything to be in the sequence
> > that is required.  (On the linker command line, crt0.o would be placed
> > first, so if the entry point is the first thing in crt0.o it will then
> > also be the first thing in the executable.)
> 
> Yes, I can do that, but that means I need to have a linker command
> line!  The way the MVS linker works, I can link my main program,
> (which obviously doesn't have crt0 in it), and, thanks to the "END"
> statement, I can specify an entry point.  This means no complaint
> from the linker about a default (and wrong) entry point, and no
> need for any linker statements.  It all automatically resolves.

I don't know exactly how your port handles this on MVS, but usually
GCC itself will invoke the linker, and will itself prepare an
appropriate command linker for the linker.  As part of this command
line, things like crt files will be specified.  You should set the
STARTFILE_SPEC macro in your back-end to do that ...

> > There doesn't seem to be an easy way to do this from the
> > compiler.  At the time compiler output is generated, the
> > original source code text isn't even kept any more; you'd
> > have to go back and re-read the original source files using
> > the line-number debug data, just as the assembler would ...
> 
> Ok, well - I would be content with just the source line number
> appearing in the output assembler.  Is this information
> available as each assembler line is output?

In current GCC, every insn contains "location" information pointing
back to source code line (and column) numbers.  However, in GCC 3.x
I think this wasn't yet present, but you had to rely on line number
notes interspersed with the insn stream.

In any case, if you build with -g and use in addition the "debug
assembler output" flag -dA the assembler output should contain
human-readable comments containing line number information.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> That depends a bit on the compiler version and optimization level,
> but (in particular in the 3.x time frame) GCC may output assembler
> code on a function-by-function basis, without necessarily reading
> in the whole source file first.

Ok, actually it doesn't matter if it doesn't work all the time.  I'll
always be compiling with -Os anyway, so it sounds like I'm in
with a chance of the whole file being read first?

If so, where is my first opportunity, in 3.2.3, to see if there's a
"main" function in this file?

>> > As crt0.o can be (and usually is) completely
>> > written in assembler, you can arrange for everything to be in the 
>> > sequence
>> > that is required.  (On the linker command line, crt0.o would be placed
>> > first, so if the entry point is the first thing in crt0.o it will then
>> > also be the first thing in the executable.)
>>
>> Yes, I can do that, but that means I need to have a linker command
>> line!  The way the MVS linker works, I can link my main program,
>> (which obviously doesn't have crt0 in it), and, thanks to the "END"
>> statement, I can specify an entry point.  This means no complaint
>> from the linker about a default (and wrong) entry point, and no
>> need for any linker statements.  It all automatically resolves.
>
> I don't know exactly how your port handles this on MVS, but usually
> GCC itself will invoke the linker, and will itself prepare an
> appropriate command linker for the linker.

GCC on MVS *only* outputs assembler.  ie you always have to
use the "-S" option.

By doing so, it turns GCC into a pure text-processing application,
which will thus work in any C90 environment.

> In current GCC, every insn contains "location" information pointing
> back to source code line (and column) numbers.  However, in GCC 3.x
> I think this wasn't yet present, but you had to rely on line number
> notes interspersed with the insn stream.
>
> In any case, if you build with -g and use in addition the "debug
> assembler output" flag -dA the assembler output should contain
> human-readable comments containing line number information.

The GCC assembler is never invoked.  After getting the assembler
output from the -S option, this is fed into IFOX00/IEV90/ASMA90.

Regardless, if line number notes are interspersed in the stream,
maybe whenever I write out an assembler instruction I will have
access to those notes and can print out a comment.

Thanks.  Paul.

Re: i370 port

[Paolo Bonzini]

>> In any case, if you build with -g and use in addition the "debug
>> assembler output" flag -dA the assembler output should contain
>> human-readable comments containing line number information.
>
> Regardless, if line number notes are interspersed in the stream,
> maybe whenever I write out an assembler instruction I will have
> access to those notes and can print out a comment.

No, that might break when you upgrade later.  GCC already has support 
for annotating the assembly output with human-readable line number info. 
  That is option -dA as Ulrich pointed out.

Only DWARF-2 output supports it currently, but if you want to use it say 
together with STABS, it is just a matter of modifying dbxout_source_line 
and add a single statement like this:

       if (flag_debug_asm)
         fprintf (asm_out_file, "\t%s %s:%d\n", ASM_COMMENT_START,
                  filename, line);

Paolo

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:
> > That depends a bit on the compiler version and optimization level,
> > but (in particular in the 3.x time frame) GCC may output assembler
> > code on a function-by-function basis, without necessarily reading
> > in the whole source file first.
> 
> Ok, actually it doesn't matter if it doesn't work all the time.  I'll
> always be compiling with -Os anyway, so it sounds like I'm in
> with a chance of the whole file being read first?
> 
> If so, where is my first opportunity, in 3.2.3, to see if there's a
> "main" function in this file?

Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3).  I don't think there is any
way in 3.2.3 to check whether there is a "main" function in the file
before it is processed ...

> > I don't know exactly how your port handles this on MVS, but usually
> > GCC itself will invoke the linker, and will itself prepare an
> > appropriate command linker for the linker.
> 
> GCC on MVS *only* outputs assembler.  ie you always have to
> use the "-S" option.
> 
> By doing so, it turns GCC into a pure text-processing application,
> which will thus work in any C90 environment.

Huh.  So the user will always have to invoke the linker manually, and
pass all the correct options (libraries etc.)?

What is the problem with having GCC itself invoke the linker, just like
it does on other platforms?

> > In current GCC, every insn contains "location" information pointing
> > back to source code line (and column) numbers.  However, in GCC 3.x
> > I think this wasn't yet present, but you had to rely on line number
> > notes interspersed with the insn stream.
> >
> > In any case, if you build with -g and use in addition the "debug
> > assembler output" flag -dA the assembler output should contain
> > human-readable comments containing line number information.
> 
> The GCC assembler is never invoked.  After getting the assembler
> output from the -S option, this is fed into IFOX00/IEV90/ASMA90.

As Paolo mentioned, the -dA flag is an option to the *compiler* that
causes it to place additional information into its output stream
(the assembler source code).


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Thanks guys for your reply.

> As Paolo mentioned, the -dA flag is an option to the *compiler* that
> causes it to place additional information into its output stream
> (the assembler source code).

[from Paolo]

> Only DWARF-2 output supports it currently, but if you want to use it say 
> together with STABS, it is just a matter of modifying dbxout_source_line 
> and add a single statement like this:
> 
>       if (flag_debug_asm)
>         fprintf (asm_out_file, "\t%s %s:%d\n", ASM_COMMENT_START,
>                  filename, line);

Ok, after a few false leads, I found something that produced a
pleasing result.  Fantastic I should say!

With this mod:

C:\devel\gcc\gcc>cvs diff debug.c
Index: debug.c
===================================================================
RCS file: c:\cvsroot/gcc/gcc/debug.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 debug.c
20a21,31
> #include "output.h"
> #include "flags.h"
>
> void
> fff (line, text)
>      unsigned int line ATTRIBUTE_UNUSED;
>      const char *text ATTRIBUTE_UNUSED;
> {
>    if (flag_debug_asm)
>    fprintf(asm_out_file, "fff %d %s\n", line, text);
> }
34c45
<   debug_nothing_int_charstar, /* source_line */
---
>   fff /*debug_nothing_int_charstar*/, /* source_line */

and the -g -dA options

I was able to get exactly what I needed:

* Function main code
fff 32 world.c
         * basic block 0
         L     2,=V(X)
         L     2,0(2)
         LTR   2,2
         BE    L2
fff 34 world.c
         * basic block 1
         MVC   88(4,13),=A(LC0)
         B     L4
L2       EQU   *
         * basic block 2
fff 38 world.c
         MVC   88(4,13),=A(LC1)
L4       EQU   *
         * basic block 3
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
fff 41 world.c
         SLR   15,15
* Function main epilogue

But let me guess - I'm not allowed to modify debug.c and have
to decide whether MVS is an sdb, xcoff, dbx, dwarf 1/2, or vms?

>> > That depends a bit on the compiler version and optimization level,
>> > but (in particular in the 3.x time frame) GCC may output assembler
>> > code on a function-by-function basis, without necessarily reading
>> > in the whole source file first.
>> 
>> Ok, actually it doesn't matter if it doesn't work all the time.  I'll
>> always be compiling with -Os anyway, so it sounds like I'm in
>> with a chance of the whole file being read first?
>> 
>> If so, where is my first opportunity, in 3.2.3, to see if there's a
>> "main" function in this file?
> 
> Hmm, it seems 3.2.x would *always* operate on a function-by-function
> basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
> recall if it was already present in 3.3).  I don't think there is any
> way in 3.2.3 to check whether there is a "main" function in the file
> before it is processed ...

Ok, I'll wait until 3.4.6 is working before attempting to get
the entry point to 0 then.  :-)

>> > I don't know exactly how your port handles this on MVS, but usually
>> > GCC itself will invoke the linker, and will itself prepare an
>> > appropriate command linker for the linker.
>> 
>> GCC on MVS *only* outputs assembler.  ie you always have to
>> use the "-S" option.
>> 
>> By doing so, it turns GCC into a pure text-processing application,
>> which will thus work in any C90 environment.
> 
> Huh.  So the user will always have to invoke the linker manually, and
> pass all the correct options (libraries etc.)?

Correct.  Very normal MVS.  Where would we be without IEWL?

> What is the problem with having GCC itself invoke the linker, just like
> it does on other platforms?

1. That requires extensions to the C90 standard.  The behaviour of
system() is undefined, much less even the existence of fork() etc.

2. The attempt to add functionality to system() in MVS has made
leaps and bounds, but has not reached the stage of being able
to detect if the SYSPRINT DCB is already open so it knows not
to reopen it, and close it, stuffing up the caller.

3. MVS compilers don't normally invoke the linker.  That's always
a separate step.  GCCMVS is an MVS compiler also.  It would
be normal to generate object code though.  But the compiler
normally generates the object code, rather than invoking the
assembler.  In any case, the facility to allocate temporary
datasets for HLASM and deciding what space parameters
should be used etc etc has not yet been determined, and is
unwieldy regardless, and the functionality doesn't exist yet
anyway, and may be years away still, if it even makes sense.

BFN.  Paul.

Re: i370 port

[Paolo Bonzini]

> Ok, after a few false leads, I found something that produced a
> pleasing result. Fantastic I should say!
>
> With this mod:
>
> C:\devel\gcc\gcc>cvs diff debug.c
> Index: debug.c
> ===================================================================
> RCS file: c:\cvsroot/gcc/gcc/debug.c,v
> retrieving revision 1.1.1.1
> diff -r1.1.1.1 debug.c
> 20a21,31
>> #include "output.h"
>> #include "flags.h"
>>
>> void
>> fff (line, text)
>> unsigned int line ATTRIBUTE_UNUSED;
>> const char *text ATTRIBUTE_UNUSED;
>> {
>> if (flag_debug_asm)
>> fprintf(asm_out_file, "fff %d %s\n", line, text);
>> }

with s/fff/ASM_COMMENT_START/ and with a proper function name, this is 
actually an almost acceptable patch.  Only, you also have to do 
app_enable/app_disable (search for the other occurrences of 
flag_debug_asm in dwarf2out.c, they also explain why this is needed). 
These probably can be moved to common code in general.

> But let me guess - I'm not allowed to modify debug.c and have
> to decide whether MVS is an sdb, xcoff, dbx, dwarf 1/2, or vms?

No, that's fine.  -dA can actually be handled by common code.

Paolo

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> > What is the problem with having GCC itself invoke the linker, just like
> > it does on other platforms?
> 
> 1. That requires extensions to the C90 standard.  The behaviour of
> system() is undefined, much less even the existence of fork() etc.
> 
> 2. The attempt to add functionality to system() in MVS has made
> leaps and bounds, but has not reached the stage of being able
> to detect if the SYSPRINT DCB is already open so it knows not
> to reopen it, and close it, stuffing up the caller.
> 
> 3. MVS compilers don't normally invoke the linker.  That's always
> a separate step.  GCCMVS is an MVS compiler also.  It would
> be normal to generate object code though.  But the compiler
> normally generates the object code, rather than invoking the
> assembler.  In any case, the facility to allocate temporary
> datasets for HLASM and deciding what space parameters
> should be used etc etc has not yet been determined, and is
> unwieldy regardless, and the functionality doesn't exist yet
> anyway, and may be years away still, if it even makes sense.

I cannot really comment on what would be desirable behaviour for
MVS ...   Just as an implementation note, while it is true that
the GCC compiler driver needs to be able to execute other processes
(preprocessor, compiler, assembler, linker) as sub-tasks, it does
not require the full POSIX system/fork/exec functionality to do so.
GCC relies on the libiberty "pex" family of routines, which are
much more narrow in scope, and have in fact been ported to several
non-UNIX systems, including even MS-DOS.  Providing a port of "pex"
to MVS should be much easier that porting a full Unix "system" or
"fork" feature.

B.t.w. if you cannot execute sub-tasks at all, how does the
MVS GCC invoke the preprocessor (I think this was still a
separate process in 3.2) and the core compiler (cc1) from
the compiler driver?   Do you even have a separate compiler
driver?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> GCC relies on the libiberty "pex" family of routines, which are
> much more narrow in scope, and have in fact been ported to several
> non-UNIX systems, including even MS-DOS.  Providing a port of "pex"
> to MVS should be much easier that porting a full Unix "system" or
> "fork" feature.

Ok.  But I don't even have much of system() yet.

> B.t.w. if you cannot execute sub-tasks at all, how does the
> MVS GCC invoke the preprocessor (I think this was still a
> separate process in 3.2) and the core compiler (cc1) from
> the compiler driver?   Do you even have a separate compiler
> driver?

Sleight of hand.  :-)

> #ifdef SINGLE_EXECUTABLE
>   int ret_code = 0;
> #endif
2836a2853,2872
> #ifdef SINGLE_EXECUTABLE
>      {
>          int cnt = 0;
>
>          while (commands[i].argv[cnt] != NULL)
>          {
>              cnt++;
>          }
>          if (strcmp(string, "cpp0") == 0)
>          {
>              ret_code = cpp(cnt, commands[i].argv);
>              if (ret_code != 0) break;
>          }
>          else if (strcmp(string, "cc1") == 0)
>          {
>              ret_code = toplev_main(cnt, commands[i].argv);
>              if (ret_code != 0) break;
>          }
>       }
> #else
2850c2886
<
---
> #endif
2853a2890,2892
> #ifdef SINGLE_EXECUTABLE
>     return (ret_code);


BTW, here's what I am going with:

C:\devel\gcc\gcc>cvs diff -r release-3_2_3 debug.c
Index: debug.c
===================================================================
RCS file: c:\cvsroot/gcc/gcc/debug.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 debug.c
20a21,35
> #include "output.h"
> #include "flags.h"
>
> static void
> debug_source_line (line, text)
>      unsigned int line ATTRIBUTE_UNUSED;
>      const char *text ATTRIBUTE_UNUSED;
> {
>    if (flag_debug_asm)
>    {
>        app_enable();
>        fprintf(asm_out_file, "%s %d %s\n", ASM_COMMENT_START, line, text);
>        app_disable();
>    }
> }
34c49
<   debug_nothing_int_charstar, /* source_line */
---
>   debug_source_line,  /* source_line */


Thanks again for everyone's assistance.

Just need to find out who's emitting this warning:

C:\devel\gcc\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CONFIG
_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include -d
A world.c       -g
world.c:0: warning: `-g': unknown or unsupported -g option

and it'll be a wrap.  :-)

There will be some very happy people who are currently manually
putting in __asm__ lines to get insight.  :-)

BFN.  Paul.

Re: i370 port

[Paul Edwards]

> Hmm, it seems 3.2.x would *always* operate on a function-by-function
> basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
> recall if it was already present in 3.3).  I don't think there is any
> way in 3.2.3 to check whether there is a "main" function in the file
> before it is processed ...

Ulrich, this comment got me thinking.  If global optimization is not
being done, then less of the source file would need to be in memory
at the same time.

How much memory do you think is required to process the largest
GCC 3.2.3 source file (ie when self-compiling)?

My experience is that fold-const.c requires 20 MB of memory (not
including the size of the executable) to compile with -Os.  That's
the biggest.

Is that typical/expected?

Because it just occurred to me that maybe the lack of a "normal"
implementation of alloca() is causing memory to not be released,
and it's taking more space than it needs to.

Thanks.  Paul.

Re: i370 port

[Paolo Bonzini]

> My experience is that fold-const.c requires 20 MB of memory (not
> including the size of the executable) to compile with -Os. That's
> the biggest.
>
> Is that typical/expected?

It doesn't seem too big.

> Because it just occurred to me that maybe the lack of a "normal"
> implementation of alloca() is causing memory to not be released,
> and it's taking more space than it needs to.

It may use a little more memory, but not much.

Paolo

Re: i370 port

[Paul Edwards]

>> > That depends a bit on the compiler version and optimization level,
>> > but (in particular in the 3.x time frame) GCC may output assembler
>> > code on a function-by-function basis, without necessarily reading
>> > in the whole source file first.
>>
>> Ok, actually it doesn't matter if it doesn't work all the time.  I'll
>> always be compiling with -Os anyway, so it sounds like I'm in
>> with a chance of the whole file being read first?
>>
>> If so, where is my first opportunity, in 3.2.3, to see if there's a
>> "main" function in this file?
>
> Hmm, it seems 3.2.x would *always* operate on a function-by-function
> basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
> recall if it was already present in 3.3).  I don't think there is any
> way in 3.2.3 to check whether there is a "main" function in the file
> before it is processed ...

Does that mean I could take advantage of this behaviour?  Currently
I have this change:

/* Store in OUTPUT a string (made with alloca) containing an
   assembler-name for a local static variable named NAME.
   LABELNO is an integer which is different for each call.  */

#ifdef TARGET_PDPMAC
#define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO)  ^I^I\
{^I^I^I^I^I^I^I^I^I\
  (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10);^I^I^I\
  sprintf ((OUTPUT), "__%d", (LABELNO));^I^I^I^I\
}

to give the static functions unique names within the file.

However, it has the unfortunate side-effect that this code:

#if defined(TARGET_DIGNUS) || defined(TARGET_PDPMAC)
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL)^I^I^I\
{^I^I^I^I^I^I^I^I^I\
  if (strlen (NAME) + 1 > mvs_function_name_length)^I^I^I\
    {^I^I^I^I^I^I^I^I^I\
      if (mvs_function_name)^I^I^I^I^I^I\
^Ifree (mvs_function_name);^I^I^I^I^I\
      mvs_function_name = 0;^I^I^I^I^I^I\
    }^I^I^I^I^I^I^I^I^I\
  if (!mvs_function_name)^I^I^I^I^I^I\
    {^I^I^I^I^I^I^I^I^I\
      mvs_function_name_length = strlen (NAME) * 2 + 1;^I^I^I\
      mvs_function_name = (char *) xmalloc (mvs_function_name_length);^I\
    }^I^I^I^I^I^I^I^I^I\
  strcpy (mvs_function_name, NAME);^I^I^I^I^I\
  mvs_need_to_globalize = 1;^I^I^I^I^I^I\
}
#endif

static void
i370_output_function_prologue (f, l)
     FILE *f;
     HOST_WIDE_INT l;
{
/* Don't print stack and args in PDPMAC as it makes the
   comment too long */
#ifdef TARGET_PDPMAC
  fprintf (f, "* %c-func %s prologue\n",
           mvs_need_entry ? 'X' : 'S',
           mvs_function_name);
#else

is producing this output:

* S-func __0 prologue
@@0      PDPPRLG CINDEX=1,FRAME=88,BASER=12,ENTRY=NO
         B     FEN1
         LTORG
FEN1     EQU   *
         DROP  12
         BALR  12,0
         USING *,12
PG1      EQU   *
         LR    11,1
         L     10,=A(PGT1)
* Function __0 code
* 46 world.c
         SLR   15,15
* Function __0 epilogue
         PDPEPIL
* Function __0 literal pool
         DS    0F
         LTORG
* Function __0 page table
         DS    0F
PGT1     EQU   *
         DC    A(PG1)

for this function:

static int aaa(void)
{
    return (0);
}

ie the "aaa" is being completely lost, being replaced by __0 everywhere.
Ideally the __0 would be aaa everywhere, with just the @@0 remaining
generated.

Indeed, I have just made this change:

C:\devel\gcc\gcc>cd config\i370

C:\devel\gcc\gcc\config\i370>cvs diff
cvs diff: Diffing .
Index: i370.c
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.c,v
retrieving revision 1.34
diff -r1.34 i370.c
84a85,87
> /* original name of a static variable */
> char origmvsstatic[150];
>
1457c1460
<            mvs_function_name);
---
>            mvs_need_entry ? mvs_function_name : origmvsstatic);
1599c1602,1603
<   fprintf (f, "* Function %s code\n", mvs_function_name);
---
>   fprintf (f, "* Function %s code\n",
>            mvs_need_entry ? mvs_function_name : origmvsstatic);
1787c1791,1792
<   fprintf (file, "* Function %s epilogue\n", mvs_function_name);
---
>   fprintf (file, "* Function %s epilogue\n",
>            mvs_need_entry ? mvs_function_name : origmvsstatic);
1818c1823,1824
<   fprintf (file, "* Function %s literal pool\n", mvs_function_name);
---
>   fprintf (file, "* Function %s literal pool\n",
>            mvs_need_entry ? mvs_function_name : origmvsstatic);
1821c1827,1828
<   fprintf (file, "* Function %s page table\n", mvs_function_name);
---
>   fprintf (file, "* Function %s page table\n",
>            mvs_need_entry ? mvs_function_name : origmvsstatic);

C:\devel\gcc\gcc\config\i370>cvs diff -c i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.35
diff -c -r1.35 i370.h
*** i370.h      18 Jul 2009 08:56:33 -0000      1.35
--- i370.h      20 Aug 2009 10:40:35 -0000
***************
*** 57,62 ****
--- 57,63 ----
  /* The source file module.  */

  extern char *mvs_module;
+ extern char origmvsstatic[];

  /* Compile using char instructions (mvc, nc, oc, xc).  On 4341 use this 
since
     these are more than twice as fast as load-op-store.
***************
*** 1832,1837 ****
--- 1833,1839 ----
  #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO)                \
  {                                                                     \
    (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10);                  \
+   strcpy(origmvsstatic, NAME); \
    sprintf ((OUTPUT), "__%d", (LABELNO));                              \
  }
  #else

and it is working:

* S-func aaa prologue
@@0      PDPPRLG CINDEX=1,FRAME=88,BASER=12,ENTRY=NO
         B     FEN1
         LTORG
FEN1     EQU   *
         DROP  12
         BALR  12,0
         USING *,12
PG1      EQU   *
         LR    11,1
         L     10,=A(PGT1)
* Function aaa code
* 46 world.c
         SLR   15,15
* Function aaa epilogue
         PDPEPIL
* Function aaa literal pool
         DS    0F
         LTORG
* Function aaa page table
         DS    0F
PGT1     EQU   *
         DC    A(PG1)


But is that guaranteed?

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> > Hmm, it seems 3.2.x would *always* operate on a function-by-function
> > basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
> > recall if it was already present in 3.3).  I don't think there is any
> > way in 3.2.3 to check whether there is a "main" function in the file
> > before it is processed ...
> 
> Does that mean I could take advantage of this behaviour?

I don't think this would be a good idea.

> /* Store in OUTPUT a string (made with alloca) containing an
>    assembler-name for a local static variable named NAME.
>    LABELNO is an integer which is different for each call.  */
> 
> #ifdef TARGET_PDPMAC
> #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO)  \
> { \
>   (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10); \
>   sprintf ((OUTPUT), "__%d", (LABELNO)); \
> }

How does this work?  ASM_FORMAT_PRIVATE_NAME is not supposed
to completely ignore the NAME argument, the function may well
be called with the same LABELNO but different NAME strings,
and this must not result in conflicting symbols ...

> static void
> i370_output_function_prologue (f, l)
>      FILE *f;
>      HOST_WIDE_INT l;
> {
> /* Don't print stack and args in PDPMAC as it makes the
>    comment too long */
> #ifdef TARGET_PDPMAC
>   fprintf (f, "* %c-func %s prologue\n",
>            mvs_need_entry ? 'X' : 'S',
>            mvs_function_name);
> #else

At this point, you may refer to "current_function_decl" to
retrieve information about the function currently being output.
In particular, you can retrieve the original source-level name
associated with the routine via DECL_NAME (current_function_decl).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> > Hmm, it seems 3.2.x would *always* operate on a function-by-function
>> > basis.  The unit-at-a-time mode was only introduced with 3.4 (I don't
>> > recall if it was already present in 3.3).  I don't think there is any
>> > way in 3.2.3 to check whether there is a "main" function in the file
>> > before it is processed ...
>>
>> Does that mean I could take advantage of this behaviour?
>
> I don't think this would be a good idea.

You're right.  With your new change, I was able to see the difference,
and I can see that the static functions sometimes get numbers
assigned in a different order (I think first one called), and in that case,
with my method the name ends up wrong, but yours works.

* S-func dump_new_line prologue
@@3      PDPPRLG CINDEX=4,FRAME=104,BASER=12,ENTRY=NO
* Function dump_new_line code
* Function dump_new_line epilogue
         PDPEPIL
* Function dump_new_line literal pool
         DS    0F
         LTORG
* Function dump_new_line page table
         DS    0F
* S-func dump_maybe_newline prologue (!!!! your new technique)
@@2      PDPPRLG CINDEX=5,FRAME=104,BASER=12,ENTRY=NO
         B     FEN5
         L     10,=A(PGT5)
* Function dump_new_line code (!!!!!! wrong name)

>> /* Store in OUTPUT a string (made with alloca) containing an
>>    assembler-name for a local static variable named NAME.
>>    LABELNO is an integer which is different for each call.  */
>>
>> #ifdef TARGET_PDPMAC
>> #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO)  \
>> { \
>>   (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10); \
>>   sprintf ((OUTPUT), "__%d", (LABELNO)); \
>> }
>
> How does this work?  ASM_FORMAT_PRIVATE_NAME is not supposed
> to completely ignore the NAME argument, the function may well
> be called with the same LABELNO but different NAME strings,
> and this must not result in conflicting symbols ...

I have compiled the entire GCC and not come up with any duplicate
static function names, so I think the number is always unique.

>> static void
>> i370_output_function_prologue (f, l)
>>      FILE *f;
>>      HOST_WIDE_INT l;
>> {
>> /* Don't print stack and args in PDPMAC as it makes the
>>    comment too long */
>> #ifdef TARGET_PDPMAC
>>   fprintf (f, "* %c-func %s prologue\n",
>>            mvs_need_entry ? 'X' : 'S',
>>            mvs_function_name);
>> #else
>
> At this point, you may refer to "current_function_decl" to
> retrieve information about the function currently being output.
> In particular, you can retrieve the original source-level name
> associated with the routine via DECL_NAME (current_function_decl).

Thanks a lot!  I couldn't use that directly, but this:

c:\devel\gcc\gcc\config\i370>cvs diff -r 1.37 i370.c
Index: i370.c
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.c,v
retrieving revision 1.37
retrieving revision 1.38
diff -r1.37 -r1.38
1457c1457
<            mvs_function_name);
---
>            fname_as_string(0));
1599c1599
<   fprintf (f, "* Function %s code\n", mvs_function_name);
---
>   fprintf (f, "* Function %s code\n", fname_as_string(0));
1786c1786
<   fprintf (file, "* Function %s epilogue\n", mvs_function_name);
---
>   fprintf (file, "* Function %s epilogue\n", fname_as_string(0));
1817c1817
<   fprintf (file, "* Function %s literal pool\n", mvs_function_name);
---
>   fprintf (file, "* Function %s literal pool\n", fname_as_string(0));
1820c1820
<   fprintf (file, "* Function %s page table\n", mvs_function_name);
---
>   fprintf (file, "* Function %s page table\n", fname_as_string(0));

seems to do the trick!

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> >> /* Store in OUTPUT a string (made with alloca) containing an
> >>    assembler-name for a local static variable named NAME.
> >>    LABELNO is an integer which is different for each call.  */
> >>
> >> #ifdef TARGET_PDPMAC
> >> #define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO)  \
> >> { \
> >>   (OUTPUT) = (char *) alloca (strlen ((NAME)) + 10); \
> >>   sprintf ((OUTPUT), "__%d", (LABELNO)); \
> >> }
> >
> > How does this work?  ASM_FORMAT_PRIVATE_NAME is not supposed
> > to completely ignore the NAME argument, the function may well
> > be called with the same LABELNO but different NAME strings,
> > and this must not result in conflicting symbols ...
> 
> I have compiled the entire GCC and not come up with any duplicate
> static function names, so I think the number is always unique.

Hmm, I see that in the 3.2.x code base this is indeed true.
However, in later compilers ASM_FORMAT_PRIVATE_NAME is used
for other purposes by the middle-end, not just static function
or variable names.  You definitely can get number collisions
in later compilers ...

> > At this point, you may refer to "current_function_decl" to
> > retrieve information about the function currently being output.
> > In particular, you can retrieve the original source-level name
> > associated with the routine via DECL_NAME (current_function_decl).
> 
> Thanks a lot!  I couldn't use that directly, but this:

Why not?  I'd have thought something like

  printf ("%s", IDENTIFIER_POINTER (DECL_NAME (current_function_decl)));

should work fine ...


> c:\devel\gcc\gcc\config\i370>cvs diff -r 1.37 i370.c

B.t.w. if you use the -u or -c option to cvs diff, the diffs are
a lot more readable ...

> <            mvs_function_name);
> ---
> >            fname_as_string(0));

This is a bit problematic as fname_as_string is a function defined in
the C front-end.  If you were e.g. to build the Fortran compiler, your
back-end gets linked against the Fortran front-end instead of the C
front-end, and that function simply will not be there.  Generally,
the rule is that the back-end must not directly call front-end routines.

In any case, for C source code fname_as_string does pretty much
nothing else than what I suggested above ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> I understand current GCC supports various source and target character
>> sets a lot better out of the box, so it may be EBCDIC isn't even an
>> issue any more.   If there are other problems related to MVS host
>
> I think the EBCDIC support is largely theoretical and not tested on any
> actual EBCDIC host (or target).  cpplib knows the character set name
> UTF-EBCDIC, but whenever it does anything internally that involves the
> encoding of its internal character set it uses UTF-8 rules (which is not
> something valid to do with UTF-EBCDIC).

Results are finally in.

EBCDIC (or arbitrary character set) support was introduced in 3.4.6,
and continues to be the same today, correct?

I've just succeeded today in getting gcc 3.4.6 to self-compile on an
EBCDIC host.  :-)  That's after a gcc 3.4.6 ascii to ebcdic cross-compile.

It's fascinating to look back at what it took.  Note that there are still
some relatively minor cleanups I have yet to do, but it won't change
much.

Caveats:

1. The generated (from machine definition) files are still generated on
the PC.

2. I am unable to do an optimized compile even as a cross-compile,
I get an internal error in this function:

gcse.c:

static void
compute_hash_table_work (struct hash_table *table)
{
...
  if (!current_bb) /* +++ why are we getting NULL here? */
  {
      printf("internal error in gcse\n");
      exit(EXIT_FAILURE);
  }
  FOR_EACH_BB (current_bb)

and indeed, I can't see anything that would initialize that current_bb,
so it's not that surprising that it's NULL!

3. As with gcc 3.2.3, the compiler is still producing slightly different
results on the PC vs mainframe, probably still because of floating
point comparisons being done to select the next register to use
or something like that.

4. There is one thing that doesn't have proper ASCII to EBCDIC
translation being done - the __FUNCTION__ builtin.

So here is the code generated on the PC:

         COPY  PDPTOP
         CSECT
* Program text area
@@V1     EQU   *
         DC    X'78'
         DC    X'31'
         DC    X'32'
         DC    X'33'
         DC    X'0'
LC0      EQU   *
         DC    C'%s %d %s'
         DC    X'15'
         DC    X'0'
LC1      EQU   *
         DC    C'zatest.c'
         DC    X'0'
         DS    0F
* X-func x123 prologue
X123     PDPPRLG CINDEX=0,FRAME=104,BASER=12,ENTRY=YES
         B     FEN0
         LTORG
FEN0     EQU   *
         DROP  12
         BALR  12,0
         USING *,12
PG0      EQU   *
         LR    11,1
         L     10,=A(PGT0)
* Function x123 code
         MVC   88(4,13),=A(LC0)
         MVC   92(4,13),=A(LC1)
         MVC   96(4,13),=F'5'
         MVC   100(4,13),=A(@@V1)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
* Function x123 epilogue
         PDPEPIL
* Function x123 literal pool
         DS    0F
         LTORG
* Function x123 page table
         DS    0F
PGT0     EQU   *
         DC    A(PG0)
         END

for this source:

#include <stdlib.h>

void x123(void)
{
    printf("%s %d %s\n", __FILE__, __LINE__, __FUNCTION__);
}

However, that anomaly is not integral to getting the compiler on the
mainframe, and once on the mainframe, the problem goes away
with the next pass.  :-)

I think the problem is this function:

c-decl.c:
c_make_fname_decl (tree id, int type_dep)

needs to call cpp_interpret_string or something like that to get
converted into EBCDIC.


There's not that much mainline code that needs to be changed.
You can see for youself here:

http://rapidshare.com/files/277287822/gccnew-beta51.zip

The file is 250k compressed containing diffs, but most of them are
simply the generated files (which appear as new).  Here are the
real file changes:

diff -c gccnew/gcc/builtins.c:1.1.1.1 gccnew/gcc/builtins.c:1.3
diff -c gccnew/gcc/c-common.c:1.1.1.1 gccnew/gcc/c-common.c:1.2
diff -c gccnew/gcc/c-incpath.c:1.1.1.1 gccnew/gcc/c-incpath.c:1.3
diff -c gccnew/gcc/c-opts.c:1.1.1.1 gccnew/gcc/c-opts.c:1.2
diff -c gccnew/gcc/c-parse.c:1.1.1.1 gccnew/gcc/c-parse.c:1.5
diff -c gccnew/gcc/c-pch.c:1.1.1.1 gccnew/gcc/c-pch.c:1.3
diff -c gccnew/gcc/cppcharset.c:1.1.1.1 gccnew/gcc/cppcharset.c:1.6
diff -c gccnew/gcc/cpperror.c:1.1.1.1 gccnew/gcc/cpperror.c:1.2
diff -c gccnew/gcc/cppfiles.c:1.1.1.1 gccnew/gcc/cppfiles.c:1.7
diff -c gccnew/gcc/cpplib.h:1.1.1.1 gccnew/gcc/cpplib.h:1.2
diff -c gccnew/gcc/cppmacro.c:1.1.1.1 gccnew/gcc/cppmacro.c:1.2
diff -c gccnew/gcc/cppspec.c:1.1.1.1 gccnew/gcc/cppspec.c:1.3
diff -c gccnew/gcc/gcc.c:1.1.1.1 gccnew/gcc/gcc.c:1.6
diff -c gccnew/gcc/gcc.h:1.1.1.1 gccnew/gcc/gcc.h:1.2
diff -c gccnew/gcc/gcov-io.c:1.1.1.1 gccnew/gcc/gcov-io.c:1.2
diff -c gccnew/gcc/gcov-io.h:1.1.1.1 gccnew/gcc/gcov-io.h:1.2
diff -c gccnew/gcc/gcse.c:1.1.1.1 gccnew/gcc/gcse.c:1.3
diff -c gccnew/gcc/hwint.h:1.1.1.1 gccnew/gcc/hwint.h:1.2
diff -c gccnew/gcc/longlong.h:1.1.1.1 gccnew/gcc/longlong.h:1.2
diff -c gccnew/gcc/opts.c:1.1.1.1 gccnew/gcc/opts.c:1.2
diff -c gccnew/gcc/opts.h:1.1.1.1 gccnew/gcc/opts.h:1.3
diff -c gccnew/gcc/opts.sh:1.1.1.1 gccnew/gcc/opts.sh:1.1.1.2
diff -c gccnew/gcc/pretty-print.c:1.1.1.1 gccnew/gcc/pretty-print.c:1.2
diff -c gccnew/gcc/read-rtl.c:1.1.1.1 gccnew/gcc/read-rtl.c:1.2
diff -c gccnew/gcc/real.c:1.1.1.1 gccnew/gcc/real.c:1.3
diff -c gccnew/gcc/system.h:1.1.1.1 gccnew/gcc/system.h:1.2
diff -c gccnew/gcc/toplev.c:1.1.1.1 gccnew/gcc/toplev.c:1.3
diff -c gccnew/gcc/varasm.c:1.1.1.1 gccnew/gcc/varasm.c:1.2
diff -c gccnew/gcc/version.c:1.1.1.1 gccnew/gcc/version.c:1.2
diff -c gccnew/gcc/config/i370/i370-c.c:1.1.1.1 
gccnew/gcc/config/i370/i370-c.c:1.2
diff -c gccnew/gcc/config/i370/i370-protos.h:1.1.1.1 
gccnew/gcc/config/i370/i370-protos.h:1.2
diff -c gccnew/gcc/config/i370/i370.c:1.1.1.1 
gccnew/gcc/config/i370/i370.c:1.23
diff -c gccnew/gcc/config/i370/i370.h:1.1.1.1 
gccnew/gcc/config/i370/i370.h:1.15
diff -c gccnew/gcc/config/i370/i370.md:1.1.1.1 
gccnew/gcc/config/i370/i370.md:1.3
diff -c gccnew/gcc/config/i370/linux.h:1.1.1.1 
gccnew/gcc/config/i370/linux.h:1.1.1.2
diff -c gccnew/gcc/config/i370/oe.h:1.1.1.1 
gccnew/gcc/config/i370/oe.h:1.1.1.2
diff -c gccnew/include/fnmatch.h:1.1.1.1 gccnew/include/fnmatch.h:1.2
diff -c gccnew/include/safe-ctype.h:1.1.1.1 
gccnew/include/safe-ctype.h:1.1.1.2
diff -c gccnew/include/sort.h:1.1.1.1 gccnew/include/sort.h:1.2
diff -c gccnew/include/xregex2.h:1.1.1.1 gccnew/include/xregex2.h:1.2
diff -c gccnew/libiberty/argv.c:1.1.1.1 gccnew/libiberty/argv.c:1.4
diff -c gccnew/libiberty/concat.c:1.1.1.1 gccnew/libiberty/concat.c:1.2
diff -c gccnew/libiberty/cplus-dem.c:1.1.1.1 
gccnew/libiberty/cplus-dem.c:1.2
diff -c gccnew/libiberty/fdmatch.c:1.1.1.1 gccnew/libiberty/fdmatch.c:1.2
diff -c gccnew/libiberty/getpagesize.c:1.1.1.1 
gccnew/libiberty/getpagesize.c:1.2
diff -c gccnew/libiberty/getpwd.c:1.1.1.1 gccnew/libiberty/getpwd.c:1.2
diff -c gccnew/libiberty/getruntime.c:1.1.1.1 
gccnew/libiberty/getruntime.c:1.2
diff -c gccnew/libiberty/hashtab.c:1.1.1.1 gccnew/libiberty/hashtab.c:1.2
diff -c gccnew/libiberty/hex.c:1.1.1.1 gccnew/libiberty/hex.c:1.1.1.2
diff -c gccnew/libiberty/lrealpath.c:1.1.1.1 
gccnew/libiberty/lrealpath.c:1.2
diff -c gccnew/libiberty/make-temp-file.c:1.1.1.1 
gccnew/libiberty/make-temp-file.c:1.2
diff -c gccnew/libiberty/md5.c:1.1.1.1 gccnew/libiberty/md5.c:1.2
diff -c gccnew/libiberty/mkstemps.c:1.1.1.1 gccnew/libiberty/mkstemps.c:1.2
diff -c gccnew/libiberty/obstack.c:1.1.1.1 gccnew/libiberty/obstack.c:1.2
diff -c gccnew/libiberty/physmem.c:1.1.1.1 gccnew/libiberty/physmem.c:1.2
diff -c gccnew/libiberty/regex.c:1.1.1.1 gccnew/libiberty/regex.c:1.2
diff -c gccnew/libiberty/safe-ctype.c:1.1.1.1 
gccnew/libiberty/safe-ctype.c:1.4
diff -c gccnew/libiberty/vasprintf.c:1.1.1.1 
gccnew/libiberty/vasprintf.c:1.1.1.2
diff -c gccnew/libiberty/xmalloc.c:1.1.1.1 gccnew/libiberty/xmalloc.c:1.3
diff -c gccnew/libiberty/xmemdup.c:1.1.1.1 gccnew/libiberty/xmemdup.c:1.2
diff -c gccnew/libiberty/xstrdup.c:1.1.1.1 gccnew/libiberty/xstrdup.c:1.2

(most files are just a few lines of change though).

The most intrusive change was the #include processing which is
done differently on MVS.

Anyway, I'm planning on spending a bit more time consolidating this
build.  Not sure if the optimization problem can be solved, but even if
it can't, at least all the i370 code is now consolidated ready for the
push forward.  Hopefully these issues are more readily solved in the
latest codebase.

Hopefully also some of those other minor issues (like including
non-standard header files like sys/types) can also be remedied.  :-)

This has certainly taken a while.  The number of people who have
asked me why I don't use 3.4.6 as if it is trivial to do these things,
just change a couple of numbers surely.  :-)

Interesting how well the EBCDIC conversion held up too.  GCC 3.2.3
was a lot more intrusive to get working in that regard.

Let me know if you find anything that should have been done
differently too.  :-)

BFN.  Paul.

Re: i370 port - in search of hooks

[Paul Edwards]

I'm making quite good progress with cleaning up the 3.4.6 i370
port.  I've even got optimization working to some degree.

Meanwhile, on a different machine (a Linux machine I program
on on the way to/from work), I have managed to build 4.4.0,
which means I have an environment to work on a more modern
version of GCC.

That modern version is what I would like to ask about today.
Leaving aside the issue of the actual target, I'm more interested
in the intrusive hooks I expect I will need (I won't know until
I start doing the work, and I can't do that until I find out whether
4.4 is good enough - chicken and egg).  Here is what I needed
for 3.4.6:


1. Ability to build a standalone executable.  Simply put, I need
gcc to do a function call like this:

#ifdef SINGLE_EXECUTABLE
     {
         int cnt = 0;

         while (commands[i].argv[cnt] != NULL)
         {
             cnt++;
         }
         if (strcmp(string, "cc1") == 0)
         {
             ret_code = toplev_main(cnt, commands[i].argv);
             if (ret_code != 0) break;
         }
      }
#else

Doesn't need to be exactly like that, but some sort of hook to be
made available so that I can bypass system() or any variation of
that.  C90 doesn't guarantee that system() will do anything in
particular.  And my C environment indeed doesn't work too well
if you try that.  Can't have two programs opening and closing
the same DDNAME.  Can only have 100 characters worth of
parameters too.


2. A completely different way of handling include files.  After going
through the normal remap process, I then want the following
transformations:

#include "fred.h"

gets translated into an fopen("dd:include(fred)", "r")

#include <fred.h>

gets translated into an fopen("dd:sysincl(fred)", "r")

None of this checking to see if something is a directory etc.  There's
no such call available in C90, nor my C library on MVS.  The code
above looks trivial enough, but when it's time to actually find where
to put that, it's non-trivial.


3. There is some complicated parameter lookup facility - it does a binary
search on the parameters.  This requires a whole lot of infrastructure to
be present to generate the code.  Infrastructure which I don't have.  I'd
like a simple sequential search to be available as an option I can
activate.


4. There are a whole lot of includes that don't exist, like sys/types.h, and
I'd like them to be masked out like all other includes are done (even
things that are part of C90 have masks!!!).


5. It'd be cool if some of the names could be unique in the first 8 
characters
(C90 guarantees 6 for externals, but I have the luxury of 8).  I have a
mostly non-intrusive way of remapping everything, but there are a few
that I need to do intrusively, because I can't #define away something
that is already #defined.  Problem is compounded by the fact that
I link together code that normally isn't linked together.  Note that I don't
need things like an assembler and linker linked in together - I just need
the stuff required for the "-S" option to work.  ie text file (ie C code) 
in,
and text file (ie assembler code) out - a text processing program that
should be (and in fact, has already been made that way) possible to
do in pure C90.


6. It would be nice if all the non-C90 Posix functions were masked out,
but so far I have been able to kludge around that without requiring a
lot of intrusive changes.  It would be good to get the worst of them
out though.


My questions are:

1. Are changes like the above likely to be accepted into the head version
going forward?

2. If they are, what version should I work on to get that to happen?


Ideally I'd like to work on a stable version, perhaps 4.4, and later have
those changes merged onto the head.  But I fear if I do that I will end
up in the same position I am in now with 3.4.6, ie too many changes
such that my patches are never actually relevant.

But it's quite daunting to get this working at all.

So I thought that what I might be able to do instead is get the hooks
in place first.  Not necessarily all at once.  Possibly over the course
of a year.

Eventually all the hooks will exist, there will be a stable release cut
containing all the hooks I need, and then I may be in with a chance of
getting i370 working on that environment.  That would also be done
over the course of a year or whatever, as the GMP and MPFR need to
be set up on MVS too (just having a S/390 port is not sufficient - I
need S/370 HLASM).

Hopefully at the end of that process, I'll have an i370 port that is done
in a "standard" way so that updating to the latest GCC is fairly trivial
*regardless* of whether the i370 port is included in GCC proper due
to the yet more technical challenges that requires, another job for
another year.  :-)

This is a parallel effort to my 3.4.6 work which is done on a different
PC at a different time.  3.4.6 is mostly about getting it to run on
real MVS.  4.4/x is simply to get a cross-compile to work for now.

Thanks.  Paul.

Re: i370 port

[Paul Edwards]

>> It was dropped from GCC 4 when there was supposedly no
>> maintainer available.  Actually, Dave Pitts and myself were
>> both maintaining it at that time, but we were both still working
>> on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
>> last time it was included in the normal GCC distribution.
>
> (For reference, the port was removed in SVN revision 77216; before then it
> had had various largely mechanical changes as part of changes to multiple
> back ends or target-independent code, with r69086 as the last vaguely
> i370-only change but no changes appearing to come from someone
> specifically working and testing on i370 for some years before then.  "svn
> log svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i370@77215" shows the
> history.)

I just took a look to see if there was anything changed on the head
that didn't make it into 3.4.6.  Short answer: no.

Long answer:

C:\devel\gccoff>diff gccnew gcchead
Only in gcchead: .svn
diff gccnew/i370.h gcchead/i370.h
530,531c530
< #define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT, N_NAMED_ARGS) 
\
<   ((CUM) = 0)
---
> #define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT)  ((CUM) = 0)

I just need to delete that N_NAMED_ARGS when upgrading.

I'm sure that will be the least of my worries though.  I'm more
worried about things like the below.  :-)

Incidentally, 15 years of effort to get a hosted GCC compiler on
real MVS (not USS) came to realization on Jan 11, 2004:

http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg00031.html

(although it wasn't released until March 2004 when it was good
enough to self-compile.)

The revision that deleted i370 was made on Feb 4th, 2004.  How's
that for timing?

Incidentally, while it may look from this angle like the i370 port
wasn't being worked on, it's actually had a huge amount of
effort put into it.  The activity has just been in different forums
(like the one above).  It wasn't just GCC though.  A lot of
infrastructure was required.  E.g. even the assembler didn't
support such a huge number of externals that was being
generated by GCC, so first I hacked around that in GCC
itself, mapping a whole lot of "unused" flags to be the same,
and then reversed that out when someone came up with a
modification to the assembler.

Then we needed to switch from 24-bit mode to 31-bit mode to
get the required memory for GCC to self-compile.  Another
huge enterprise.

> I would encourage going through all the changes made to the i370 port on
> GCC mainline, after 3.1/3.2 branched and before the port was removed, to
> see what should be merged into your version for mainline; ultimately it
> would be up to you how you get it updated for all the mechanical changes
> on mainline since 3.2, but those changes (see command above to get logs)
> may be a useful guide to how to do some of the updates.

All the merging has already been done in the 3.4.6 effort.  The only
thing that I know of that is still "at large" is someone else who was
working "offline" and made some changes.  Specifically this:

http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg00008.html

as I just discovered the same problem with both of these strict moves
now that I too am using 3.4.6.

The i370.md looks correct to me (this is the movstricthi one):

> ;(define_insn ""
> ;  [(set (strict_low_part (match_operand:HI 0 "register_operand" "+d"))
> ;     (match_operand:HI 1 "general_operand" "dSi"))]
> ;  ""
> ;  "*
> ;{
> ;  check_label_emit ();
> ;  if (REG_P (operands[1]))
> ;    {
> ;      mvs_check_page (0, 8, 0);
> ;      return \"STH   %1,\" CONVLO \"(,13)\;ICM       %0,3,\" CONVLO 
> \"(13)\";

> ;    }
> ;  else if (GET_CODE (operands[1]) == CONST_INT)
> ;    {
> ;      mvs_check_page (0, 4, 2);
> ;      return \"ICM   %0,3,%H1\";
> ;    }
> ;  mvs_check_page (0, 4, 0);
> ;  return \"ICM       %0,3,%1\";
> ;}"
> ;   [(set_attr "length" "8")]
> ;)

but I have had to comment it out, because otherwise I get code like
this generated:

L691     EQU   *
         SLR   2,2
         IC    2,0(8)
         LA    5,92(0,0)
         CLR   2,5
         BE    L699
         BH    L702
         ICM   5,3,=H'64'
         BE    L696
         ICM   5,3,=H'78'
         BE    L694
         B     L701

ie the LA and CLR combination are what I would expect, but gcc 3.4.6
has decided to use an ICM to move a constant in, which seems an
awful waste to me instead of using LA, but the real problem is that
it hasn't generated a CLR afterwards (it needs to compare against
register 2), so isn't taking a branch it should be.

I didn't have this problem in 3.2.3, which has a virtually identical
machine definition.  But I'd be really surprised to find a serious
compiler bug outside of the i370 code?!  I assume I'm just looking
in the wrong spot.

But at least I'm making progress.  :-)

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

Just one comment on this particular point:

> 4. There is one thing that doesn't have proper ASCII to EBCDIC
> translation being done - the __FUNCTION__ builtin.

It looks this was indeed a bug that was fixed for GCC 4.0.0:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01773.html
(note that there were some minor revisions to the patch
before it was committed).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi Joseph. (reviving a thread from 2009)

I have been streamlining the execution
of MVS (i370) via my "runmvs" script
recently, and now it only takes a few
seconds to do a test on MVS because
I have taken out all the unnecessary
pauses and made lots of other
improvements, and bypassing bugs
in Hercules.

Numerous other i370 bugs have been
fixed in GCC 3.2.3 too.

So I decided it was time to take a look
at the test suite to see what state that
was in.

With the aid of a script (below), I got
the following results:

C:\devel\gcc\gcc\config\i370\test>showres

C:\devel\gcc\gcc\config\i370\test>grep passed results.txt   | wc
    516    1032   10278

C:\devel\gcc\gcc\config\i370\test>grep failed results.txt   | wc
    117     234    2373

C:\devel\gcc\gcc\config\i370\test>


I looked at the first few errors. One
was deficiencies with "long long"
which is currently in the "too hard"
basket.

Some were ASCII assumptions (the
i370 port is EBCDIC).

And there was a genuine bug which I
have passed on to Dave Pitts for
analysis.

Regarding the ASCII errors, here’s an
example:

C:\devel\gcc\gcc\testsuite\gcc.c-torture\execute>type 20000412-3.c
typedef struct {
  char y;
  char x[32];
} X;

int z (void)
{
  X xxx;
  xxx.x[0] =
  xxx.x[31] = '0';
  xxx.y = 0xf;
  return f (xxx, xxx);
}

int main (void)
{
  int val;

  val = z ();
  if (val != 0x60)
    abort ();
  exit (0);
}

int f(X x, X y)
{
  if (x.y != y.y)
    return 'F';

  return x.x[0] + y.x[0];
}


They have assumed that '0' is 0x30,
but on EBCDIC it is 0xf0.

The documentation says:

C:\devel\gcc\gcc\testsuite>grep PORTABLE readme.gcc
DO NOT PUT NON-PORTABLE TESTCASES IN gcc.c-torture.


So what do you suggest I do with this class
of error?

The choices seem to be:

1. Remove/ignore it as it is non-portable so
shouldn't be there in the first place.

2. Create a new internal define like __EBCDIC__
and if that is set, do something different.

3. Create a user-define like -DEBCDIC to be
tested.

4. Do something like:

#if '0' == 0x30

(untested)

5. Use an existing define, like __MVS__
and if that is set, do something-or-other.


Any suggestions?

I know 3.2.3 is very old, but this is a very
long road, and this is where the most
stable i370.md environment is.

BTW, I saw someone mention something
about a "compile farm". MVS/380 is a
freely available i370 platform which
allows you to run tests on MVS pretty
easily, if a time comes when people
want to run tests on MVS to see if
their code works on EBCDIC as C90
allows.

Here is what it looks like on my system:

Just call this script:

call mvsgccr cprog.c output.txt

and it produces an output file that
includes:

07.28.30 JOB    1  $HASP373 MVSGCCR  STARTED - INIT  3 - CLASS C - SYS BSP1
07.28.30 JOB    1  IEF403I MVSGCCR - STARTED - TIME=07.28.30
07.28.30 JOB    1  IEFACTRT - Stepname  Procstep  Program   Retcode
07.28.31 JOB    1  MVSGCCR    S1        CREATE    IEFBR14   RC= 0000
07.28.31 JOB    1 *IEF233A M 401,PCTOMF,,MVSGCCR,COMP
07.28.32 JOB    1  MVSGCCR    S1        COMP      GCCNOMM   RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        ASM       ASMA90    RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        LKED      IEWL      RC= 0000
07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0000
07.28.33 JOB    1  IEF404I MVSGCCR - ENDED - TIME=07.28.33
07.28.33 JOB    1  $HASP395 MVSGCCR  ENDED

On a failure of a test case, this line:

07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0000

changes to:

07.28.33 JOB    1  MVSGCCR    S1        EXECC     CPROG     RC= 0012


MVS is a very interesting environment
in my opinion, and it's cool to have
code working there too.

I was thinking that maybe for people
who don't wish to install MVS/380
or TK4- on their system, there could
be some sort of hacked ftp so that
people could go:

ftp some.site
put cprog.c
put go.txt (this hangs while the C
program is compiled)
get output.txt
bye

Or for the more generic case:
ftp some.different.site
put in.jcl
put in.zip
put go.txt (hangs possibly 10 minutes)
get output.txt
get out.zip
bye

(for when you wish to build an entire
application, like "sed", on MVS).

go.txt could have the required runmvs
command, such as:

runmvs in.jcl output.txt in.zip out.zip


Usage here:

C:\mvs380>runmvs
Usage runmvs jcl.file print.file [aux_input.file|none] 
[aux_output.file|none] [ascii|binary|rdwund|rdwvar|vart] [ascii|binary] 
[awstap.file|none]
e.g. runmvs compile.jcl output.txt world.c world.s ascii ascii
or runmvs buildgcc.jcl output.txt source.zip xmit.dat
default is for files (if provided) to be binary


BTW, is that the main testsuite I should
be running? There's 633 C files there. Is
that enough, given that I'm only building
and testing C, or should I also compile
the stuff in the "compile" directory at the
same level as "execute"?

Thanks. Paul.





C:\devel\gcc\gcc\config\i370\test>type onecomp.bat
rem this should be run in a directory under config/i370
copy ..\..\..\testsuite\gcc.c-torture\execute\%1 cprog.c
call mvsgccr cprog.c output.txt
grep "EXECC     CPROG     RC= 0000" output.txt
if errorlevel 1 goto bad
echo %1 passed >>results.txt
goto exit
:bad
echo %1 failed >>results.txt
:exit

C:\devel\gcc\gcc\config\i370\test>



C:\devel\gcc\gcc\config\i370\test>head dotests.bat
del results.txt

call onecomp 20000112-1.c
call onecomp 20000113-1.c
call onecomp 20000121-1.c
call onecomp 20000205-1.c
call onecomp 20000217-1.c
call onecomp 20000223-1.c
call onecomp 20000224-1.c
call onecomp 20000225-1.c

C:\devel\gcc\gcc\config\i370\test>





-----Original Message----- 
From: Joseph S. Myers
Sent: Saturday, June 6, 2009 1:02 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

On Sat, 6 Jun 2009, Paul Edwards wrote:

> The port is to a pure C90 environment (ie not posix, not unix).  It was a
> major effort to achieve that, and it has only just been completed to the
> point where the compiler recompiles itself with full optimization.  The
> environment where it runs is not set up to run shell scripts or makes
> or test suites.  It's set up to run JCL, and there's a stack of JCL card
> decks to allow GCC to compile, which would be good to have included
> in the i370 directory.

You can test a cross compiler if you have some way of copying a test
executable to the i370 system, running it and getting its output and exit
status back (actually you don't need to be able to get the exit status
since DejaGnu has wrappers to include it in the output if needed).  There
is no need for the target to be able to run shell scripts or makes.  You
would need to write your own DejaGnu board file that deals with copying
to/from the i370 system and running programs there.  The testsuite
routinely runs for much more limited embedded systems (using appropriate
board files).

-- 
Joseph S. Myers
joseph@codesourcery.com 

s390 port

[Paul Edwards]

Hi Ulrich.

Sorry for the necro - things happen slowly Down Under. :-)

Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos

(just a hobby, won't be big and professional like Linux)

We got the IPL process in place on ESA/390, and then
I decided that the next thing to do would be to switch
to z/Arch so that we could get rid of the AMODE 31
architectural limit on 32-bit programs.

It all worked fine, and we were able to use GCC 11 to
target S/390 and use the -m31 to generate 32-bit code,
run it under z/Arch as AM64, sort of making it the
equivalent of AM32. Really it is the equivalent of
AM-infinity, and there's the rub - GCC 11 is generating
negative indexes, which cause memory above 4 GiB
to be accessed (instead of wrapping at 2/4 GiB), which
of course fails.

Do you have any idea how to stop the S/390 target
from generating negative indexes? I thought the
solution might be to change the Pmode to DImode
even for non-TARGET64, but as you can see here:

http://www.pdos.org/gccfail.png

we got an internal compile error - maximum number
of generated reload insns per insn achieved (90).

I then tried changing the other SImode reference
(CASE_VECTOR_MODE) to DImode too, but that gave
the same internal error.

Here is what the failure looks like (see the large R4):

01:28:27 PSW=00042001 80000000 0000000000005870 INST=A73A0001     AHI   3,1 
add_halfword_immediate
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B2
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 PSW=00042001 80000000 0000000000005874 INST=42142FFF     STC 
1,4095(4,2)            store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 HHCCP014I CPU0000: Addressing exception CODE=0005 ILC=4
01:28:27 PSW=00042001 80000000 0000000000005878 INST=42142FFF     STC 
1,4095(4,2)            store_character
01:28:27 R:000000010009E578: Translation exception 0005
01:28:27 R0=00000000000001FD R1=00000000000000E2 R2=000000000009E579 
R3=00000000000080B3
01:28:27 R4=00000000FFFFF000 R5=000000000001E5C8 R6=0000000000007FFF 
R7=0000000000002000
01:28:27 R8=000000000000201F R9=0000000000000000 RA=00000000000080B0 
RB=00000000000080B2
01:28:27 RC=000000000009E580 RD=0000000000008138 RE=0000000000007B4C 
RF=000000000001E4E4
01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 80000000 
0000000000000444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown

Any idea what we can do?

Thanks. Paul.




-----Original Message----- 
From: Ulrich Weigand
Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:

> In addition, that code has been ported to GCC 3.4.6, which is now
> working as a cross-compiler at least.  It's still some months away
> from working natively though.  It takes a lot of effort to convert
> the Posix-expecting GCC compiler into C90 compliance.  This has
> been done though, in a way that has minimal code changes to the
> GCC mainline.

You're referring to building GCC for a non-Posix *host*, right?
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?

> Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
> HLASM, isn't 370, isn't C90, isn't MVS.  It may well be possible to
> change all those things, and I suspect that in a few years from now
> I may be sending another message asking what I need to do to get
> all my changes to the s390 target into the s390 target.  At that time,
> I suspect there will be a lot of objection to "polluting" the s390 target
> with all those "unnecessary" things.

Actually, I would really like to see the s390 target optionally support
the MVS ABI and HLASM assembler format, so I wouldn't have any objection
to patches that add these features ...

I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more.   If there are other problems related to MVS host
support, I suppose those would need to be fixed in common code anyway,
no matter whether the s390 or i370 back-ends are used.

The only point in your list I'm sceptical about is 370 architecture
support -- I don't quite see why this is still useful today (the s390
port does require at a minimum a S/390 G2 with the branch relative
instructions ... but those have been around for nearly 15 years).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com 

Re: s390 port

[Ulrich Weigand]

Hi Paul,

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 10:15:44:

> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we were able to use GCC 11 to
> target S/390 and use the -m31 to generate 32-bit code,
> run it under z/Arch as AM64, sort of making it the
> equivalent of AM32. Really it is the equivalent of
> AM-infinity, and there's the rub - GCC 11 is generating
> negative indexes, which cause memory above 4 GiB
> to be accessed (instead of wrapping at 2/4 GiB), which
> of course fails.

Can you elaborate what exactly your goals are?  The point
of the -m31 vs. -m64 option is exactly to match the
AMODE 31 vs. AMODE 64 hardware distinction, so trying to
run -m31 code in AMODE 64 is not supposed to work.

Bye,
Ulrich

Re: s390 port

[Paul Edwards]

Hi Ulrich.

Thanks a lot for your reply.

Could you give me an example of an instruction
generated by –m31 that is not expected to work
on an AM64 system?

E.g. the 32-bit

LR R2,R3

will definitely work on AM64.

So what specifically won’t work? How many different
things won’t work?

Thanks. Paul.




From: Ulrich Weigand 
Sent: Friday, September 3, 2021 12:34 AM
To: Paul Edwards 
Cc: gcc@gcc.gnu.org ; Ulrich Weigand 
Subject: Re: s390 port

Hi Paul,

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 10:15:44:

> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
> 
> It all worked fine, and we were able to use GCC 11 to
> target S/390 and use the -m31 to generate 32-bit code,
> run it under z/Arch as AM64, sort of making it the
> equivalent of AM32. Really it is the equivalent of
> AM-infinity, and there's the rub - GCC 11 is generating
> negative indexes, which cause memory above 4 GiB
> to be accessed (instead of wrapping at 2/4 GiB), which
> of course fails.

Can you elaborate what exactly your goals are?  The point
of the -m31 vs. -m64 option is exactly to match the
AMODE 31 vs. AMODE 64 hardware distinction, so trying to
run -m31 code in AMODE 64 is not supposed to work.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand]

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 16:50:35:

> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?

Well, everything related to address computation, of course.

For example, GCC may use LA on -m31 to implement a
31-bit addition, while it may use LA on -m64 to
implement a 64-bit addition.

Bye,
Ulrich

Re: s390 port

[Paul Edwards]

Hi Ulrich.

I just checked my copy of s390.md and I don’t see
LA being used for arithmetic.

If your copy of s390.md is using LA for arithmetic
then would it be possible to have an option to
use a normal mathematics instruction instead of
LA?

Do you have any more examples besides LA being
used for maths instead of a proper maths instruction?

Also, I just realized – if GCC is using LA for maths
for 32-bit registers, then values will be limited to
2 GiB instead of 4 GiB for unsigned, but that is not
the case.

BFN. Paul.




From: Ulrich Weigand 
Sent: Friday, September 3, 2021 12:53 AM
To: Paul Edwards 
Cc: gcc@gcc.gnu.org ; Ulrich Weigand 
Subject: Re: s390 port

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 16:50:35:

> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?

Well, everything related to address computation, of course.

For example, GCC may use LA on -m31 to implement a
31-bit addition, while it may use LA on -m64 to
implement a 64-bit addition.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand]

Hi Paul,

> I just checked my copy of s390.md and I don’t see
> LA being used for arithmetic.

This would be the "*la_31" and "*la_31_and" patterns.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)

> If your copy of s390.md is using LA for arithmetic
> then would it be possible to have an option to
> use a normal mathematics instruction instead of
> LA?

LA was just an example.  It doesn't usually make sense
to reason on an "use instruction X" basis, that's not
how compiler optimizations work.  You rather start with
a set of semantic invariants and then make sure those
are preserved through all transformations.

Therefore again my question, what is the actual goal
you want to achieve?   I'm still not sure I understand
that ...

> Also, I just realized – if GCC is using LA for maths
> for 32-bit registers, then values will be limited to
> 2 GiB instead of 4 GiB for unsigned, but that is not
> the case.

That's why GCC makes sure to only use the instruction
when a 31-bit addition is wanted.  This can be the
case either when GCC can prove that the involved
operands are pointer values (which are by definition
restricted to 31-bit values in -m31 mode), or when
there is an explict 31-bit addition (using e.g. an
& 0x7fffffff) in the source code.

Bye,
Ulrich

Re: s390 port

[Paul Edwards]

>> I just checked my copy of s390.md and I don’t see
>> LA being used for arithmetic.

> This would be the "*la_31" and "*la_31_and" patterns.
Sorry, I did a grep for “LA”, forgetting that
s390.md doesn’t use uppercase instructions.

> (Note that the addition is implicit in the use of
> the "address_operand" constraint.)

If it is an address we are talking about, then that LA
instruction is going to work perfectly fine in AM24,
AM31 and AM64, and in the AM64 case it is going
to be the equivalent of AM32, so maybe the s390
port could have a “-m32” option for use when
running 32-bit applications as AM64?

>> If your copy of s390.md is using LA for arithmetic
>> then would it be possible to have an option to
>> use a normal mathematics instruction instead of
>> LA?

> LA was just an example.  It doesn't usually make sense
> to reason on an "use instruction X" basis, that's not
> how compiler optimizations work.  You rather start with
> a set of semantic invariants and then make sure those
> are preserved through all transformations.

Ok, that’s above my head.

> Therefore again my question, what is the actual goal
> you want to achieve?   I'm still not sure I understand
> that ...

I would like to know what is required to implement
“-m32” in the S/390 target. I realize that z/Arch
doesn’t have a specific AM32, but I don’t need a
specific AM32. What would actually happen if you
coded a “-m32” and then ran it in an AM64
environment?

My experiments show “with one single problem
discovered so far, actually –m31 and –m32 are
identical and work fine under AM64”.

>> Also, I just realized – if GCC is using LA for maths
>> for 32-bit registers, then values will be limited to
>> 2 GiB instead of 4 GiB for unsigned, but that is not
>> the case.

> That's why GCC makes sure to only use the instruction
> when a 31-bit addition is wanted.  This can be the
> case either when GCC can prove that the involved
> operands are pointer values (which are by definition
> restricted to 31-bit values in -m31 mode)

The compiler doesn’t create a restriction there.
It just generates a simple LA and it works
differently depending on whether it is AM24/31/64.

> or when
> there is an explict 31-bit addition (using e.g. an
> & 0x7fffffff) in the source code.

Ok, thankyou, this is what I needed to know.
I believe I would like to have a –m32 that
drops this test. I don’t want GCC to assume
that such an AND instruction can be implemented
with the use of the “LA” instruction. I want
to see an explicit “N” instruction used. Can
I have this as part of “-m32”?

Thanks. Paul.

Re: s390 port

[Ulrich Weigand]

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 17:26:25:

> > Therefore again my question, what is the actual goal
> > you want to achieve?   I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have a specific AM32, but I don’t need a
> specific AM32. What would actually happen if you
> coded a “-m32” and then ran it in an AM64
> environment?

That depends on what that would actually do.  I'm still not
quite sure what the actual requirements are.

Is this about supporting a 4GB address space instead
of a 2GB space?  (I'm not aware of that being used
anywhere currently.)

Is it about supporting a 32-bit pointer type in an
otherwise AM64 environment?  (This is already used
by the TPF target, but the 32-bit pointer will still
refer to a 2GB address space.)

Is it something else?

In either case, what is the actual benefit of that mode?
(I.e. what benefit would justify the effort to implement it?)


> >> Also, I just realized – if GCC is using LA for maths
> >> for 32-bit registers, then values will be limited to
> >> 2 GiB instead of 4 GiB for unsigned, but that is not
> >> the case.
>
> > That's why GCC makes sure to only use the instruction
> > when a 31-bit addition is wanted.  This can be the
> > case either when GCC can prove that the involved
> > operands are pointer values (which are by definition
> > restricted to 31-bit values in -m31 mode)
>
> The compiler doesn’t create a restriction there.
> It just generates a simple LA and it works
> differently depending on whether it is AM24/31/64.

It is the other way around.  The compiler knows
exactly how the LA instruction behaves in hardware,
and will use the instruction whenever that behavior
matches the semantics of (a part of) the program.
Since the behavior of the instruction differs based
on the addressing mode, the compiler will have to
know which mode the executable will be running in.


Currently, the -m31/-m64 switch basically changes several
things (at the same time):
- the assumption on which AM the executable will run in
- the (used) size of a general-purpose register
- the (default) size of a pointer type
- ABI (function calling convention) details

In theory, it would be possible to split this apart
into distinct features, so that it would be possible
to implement a mode where you can have code that uses
32-bit pointers but is running in AM64 (which would
then support a 4 GB address space).

Is this what you mean by an "-m32" mode?


Basically, this would involve looking at all uses of
the TARGET_64BIT macro in the back-end and determine
which of them actually depend on which of the above
features, and disentangle it accordingly.

I guess that would be possible, but it requires a
nontrivial effort.


Bye,
Ulrich

Re: s390 port

[Paul Edwards]

Hi Ulrich. Thanks for your detailed reply.
>> > Therefore again my question, what is the actual goal
>> > you want to achieve?   I'm still not sure I understand
>> > that ...

>> I would like to know what is required to implement
>> “-m32” in the S/390 target. I realize that z/Arch
>> doesn’t have a specific AM32, but I don’t need a
>> specific AM32. What would actually happen if you
>> coded a “-m32” and then ran it in an AM64
>> environment?

> That depends on what that would actually do.  I'm still not
> quite sure what the actual requirements are.

> Is this about supporting a 4GB address space instead
> of a 2GB space?
Yes, correct.
> (I'm not aware of that being used anywhere currently.)
I’m about to use it. I just need to get past
the problem with negative indexes being used,
and I need your help.

> Is it about supporting a 32-bit pointer type in an
> otherwise AM64 environment?  (This is already used
> by the TPF target, but the 32-bit pointer will still
> refer to a 2GB address space.)

Yes, all pointers will be 32-bit – a normal 32-bit system.

> Is it something else?

Nope, you got it.

> In either case, what is the actual benefit of that mode?
> (I.e. what benefit would justify the effort to implement it?)

The “legacy” environment of z/Linux etc would be 32-bit
instead of 31-bit. IBM’s reputation will be restored. IBM
will have the best architecture on the planet. Better than
x64 because no mode switch is required shifting between
32-bit and 64-bit applications. All run as AM64 = AM-infinity.

>> >> Also, I just realized – if GCC is using LA for maths
>> >> for 32-bit registers, then values will be limited to
>> >> 2 GiB instead of 4 GiB for unsigned, but that is not
>> >> the case.
> 
>> > That's why GCC makes sure to only use the instruction
>> > when a 31-bit addition is wanted.  This can be the
>> > case either when GCC can prove that the involved
>> > operands are pointer values (which are by definition
>> > restricted to 31-bit values in -m31 mode)
>  
>> The compiler doesn’t create a restriction there.
>> It just generates a simple LA and it works
>> differently depending on whether it is AM24/31/64.

> It is the other way around.  The compiler knows
> exactly how the LA instruction behaves in hardware,
> and will use the instruction whenever that behavior
> matches the semantics of (a part of) the program.
> Since the behavior of the instruction differs based
> on the addressing mode, the compiler will have to
> know which mode the executable will be running in.

The i370 port produces code that works in AM24, AM31,
AM32 and AM64 (except for negative indexes). I’m surprised
the s390 port doesn’t too. As far as I can remember from
using IBM C, it supports execution in any AMODE too.

> Currently, the -m31/-m64 switch basically changes several
> things (at the same time)
> - the assumption on which AM the executable will run in 
> - the (used) size of a general-purpose register
> - the (default) size of a pointer type
> - ABI (function calling convention) details

> In theory, it would be possible to split this apart
> into distinct features, so that it would be possible
> to implement a mode where you can have code that uses
> 32-bit pointers but is running in AM64 (which would
> then support a 4 GB address space).

> Is this what you mean by an "-m32" mode?

Yes, correct.

> Basically, this would involve looking at all uses of
> the TARGET_64BIT macro in the back-end and determine
> which of them actually depend on which of the above
> features, and disentangle it accordingly.

> I guess that would be possible, but it requires a
> nontrivial effort.

I’d like to approach the problem from the other
direction – what modifications are required to
be made to “-m31” so that it does “-m32” instead?
I’m happy to simply retire “-m31”, but I don’t care
if both exist.

If “-m31” is retired, and made an alias for “-m32”,
my guess is that 20 lines of code need to be changed.

The most important thing is to stop generating
negative indexes.

ie if you have “char *p” and you go p[-1] I don’t
want 0xFFFFFFFF generated as an index. I instead
want a subtraction done.

I was under the impression that this was governed
by the Pmode – whether it was set to DImode or
SImode. But I tried forcing Pmode to DImode, even
for “–m31”, but it gave an internal error, which I
showed you already.

What am I missing?

Thanks. Paul.

Re: s390 port

[Andreas Schwab]

On Sep 03 2021, Paul Edwards via Gcc wrote:

> The “legacy” environment of z/Linux etc would be 32-bit
> instead of 31-bit. IBM’s reputation will be restored. IBM
> will have the best architecture on the planet. Better than
> x64 because no mode switch is required shifting between
> 32-bit and 64-bit applications. All run as AM64 = AM-infinity.

That looks like -mabi=ilp32 on aarch64, or -mx32 on x86_64.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: s390 port

[Ulrich Weigand]

"Paul Edwards" <mutazilah@gmail.com> wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.

OK, that makes things clearer.  This implies in particular:

- 4GB address space means you need to run in AMODE64

- AMODE64 means the native address size is 64 bits.  This
  implies that Pmode has to be DImode, since Pmode tells
  the compiler what the native address size is.

  Specifically, if you try to run AMODE64 with Pmode equals
  SImode, the compiler will not be aware that the hardware
  uses the high 32 bits of base and index registers, and
  will not necessarily keep them zero.  Also, the compiler
  will assume the base + index (+ displacement) arithmetic
  will operate in 32 bits -- I'm pretty sure this is
  actually the root cause of your "negative index" problem.

> > Is it about supporting a 32-bit pointer type in an
> > otherwise AM64 environment?  (This is already used
> > by the TPF target, but the 32-bit pointer will still
> > refer to a 2GB address space.)
> Yes, all pointers will be 32-bit – a normal 32-bit system.

Note that even if Pmode == DImode, you can still use 32-bit
*pointer* sizes.  This is exactly what e.g. the Intel x32
mode does (as was mentioned by Andreas).

> I’d like to approach the problem from the other
> direction – what modifications are required to
> be made to “-m31” so that it does “-m32” instead?
> I’m happy to simply retire “-m31”, but I don’t care
> if both exist.

If you want to go for an "x32" like mode, I think this
is wrong approach.  The right approach would be to
start from "-m64", and simply modify the pointer size
to be 32 bits.

This would work by setting POINTER_SIZE to 32, while
leaving everything else like for -m64.  I'm sure there
will be a few other places that need adaptation, but
it should be pretty straightforward.  You can also
check the Intel back-end where they're using the
TARGET_X32 macro.


We've thought about implementing this mode for Linux,
but decided not to do it, since it would only provide
marginal performance improvements, and has the drawback
of being another new ABI that would be incompatible to
the whole existing software ecosystem.

(The latter point may not be an issue for you if you're
looking into a completely new OS anyway.)

Bye,
Ulrich

Re: s390 port

[Paul Edwards]

> - AMODE64 means the native address size is 64 bits.  This
>  implies that Pmode has to be DImode, since Pmode tells
>  the compiler what the native address size is.

>  Specifically, if you try to run AMODE64 with Pmode equals
>  SImode, the compiler will not be aware that the hardware
>  uses the high 32 bits of base and index registers, and
>  will not necessarily keep them zero.

The compiler naturally keeps them zero. The

instructions that are used to load registers

do not pollute the high-order 32 bits.



>  Also, the compiler
>  will assume the base + index (+ displacement) arithmetic
>  will operate in 32 bits -- I'm pretty sure this is
>  actually the root cause of your "negative index" problem.


Where is this logic please? Can I do a #if 0 or similar

to disable it?


> Note that even if Pmode == DImode, you can still use 32-bit
> *pointer* sizes.  This is exactly what e.g. the Intel x32
> mode does (as was mentioned by Andreas).


I’m happy to try the approach from BOTH directions

and see which one hits “-m32” first.


>> I’d like to approach the problem from the other
>> direction – what modifications are required to
>> be made to “-m31” so that it does “-m32” instead?
>> I’m happy to simply retire “-m31”, but I don’t care
>> if both exist.

> If you want to go for an "x32" like mode, I think this
> is wrong approach.  The right approach would be to
> start from "-m64", and simply modify the pointer size
> to be 32 bits.


> This would work by setting POINTER_SIZE to 32, while
> leaving everything else like for -m64.



That will generate 64-bit z/Arch instructions.

I wish to generate ESA/390 instructions.



> I'm sure there
> will be a few other places that need adaptation, but
> it should be pretty straightforward.

No, modifying GCC is beyond my ability. I

need 20 lines of code from someone who is

familiar with the system.



>  You can also
> check the Intel back-end where they're using the
> TARGET_X32 macro.


See above about beyond my ability.

> We've thought about implementing this mode for Linux,
> but decided not to do it, since it would only provide
> marginal performance improvements, and has the drawback
> of being another new ABI that would be incompatible to
> the whole existing software ecosystem.


Shouldn’t the end user be able to decide this

for themselves? No-one at all is interested in

32-bit mainframes?


> (The latter point may not be an issue for you if you're
> looking into a completely new OS anyway.)


Correct.

Thanks. Paul.

Re: s390 port

[Ulrich Weigand]

"Paul Edwards" <mutazilah@gmail.com> wrote on 03.09.2021 13:35:10:
> >  Specifically, if you try to run AMODE64 with Pmode equals
> >  SImode, the compiler will not be aware that the hardware
> >  uses the high 32 bits of base and index registers, and
> >  will not necessarily keep them zero.
> The compiler naturally keeps them zero. The
> instructions that are used to load registers
> do not pollute the high-order 32 bits.

While this is true for most instructions, the compiler will not
restrict itself to using only those.  (As just one obvious
example, the compiler may use "lay" with a negative displacement,
which will set the high bits of a GPR in AMODE64.)

It is of course possible to change the back-end to ensure that
SImode operations always leave the high part unmodified; for
example LLVM does that, because it wants to allocate the high
parts seperately for use with the high-word facility instructions.
But GCC currently does not do so.

> >  Also, the compiler
> >  will assume the base + index (+ displacement) arithmetic
> >  will operate in 32 bits -- I'm pretty sure this is
> >  actually the root cause of your "negative index" problem.
> Where is this logic please? Can I do a #if 0 or similar
> to disable it?

This is not in one single place, but spread throughout the
compiler, both common code and back-end.  I do not think it will
be possible to get the compiler to generate correct code if
you do not specify the address size correctly.  AMODE64 will
require Pmode == DImode.

(And, b.t.w. not the -m31 DImode, which is a pair of 32-bit
GPRs, but rather the -m64 DImode, which is a single 64-bit GPR.)

> > If you want to go for an "x32" like mode, I think this
> > is wrong approach.  The right approach would be to
> > start from "-m64", and simply modify the pointer size
> > to be 32 bits.
> > This would work by setting POINTER_SIZE to 32, while
> > leaving everything else like for -m64.
>
> That will generate 64-bit z/Arch instructions.
> I wish to generate ESA/390 instructions.

Why? AMODE64 exists only in z/Arch, so of course there
will be z/Arch instructions available ...

> > We've thought about implementing this mode for Linux,
> > but decided not to do it, since it would only provide
> > marginal performance improvements, and has the drawback
> > of being another new ABI that would be incompatible to
> > the whole existing software ecosystem.
> Shouldn’t the end user be able to decide this
> for themselves?

It's open source, of course everybode can decide what they
want to work on themselves.  But we decide what we spend
our own time on based on we think is useful ...

> No-one at all is interested in 32-bit mainframes?

Not any more, at least not in Linux.  Linux is pretty much
64-bit only at this point.


Bye,
Ulrich

Re: s390 port

[Paul Edwards]

>> >  Also, the compiler
>> >  will assume the base + index (+ displacement) arithmetic
>> >  will operate in 32 bits -- I'm pretty sure this is
>> >  actually the root cause of your "negative index" problem.

>> Where is this logic please? Can I do a #if 0 or similar
>> to disable it?

> This is not in one single place, but spread throughout the
> compiler, both common code and back-end.  I do not think it will
> be possible to get the compiler to generate correct code if
> you do not specify the address size correctly.
1. Is there any way to put a constraint on index
registers, to say that a particular machine can
only index in the range of –512 to +512 or some
other arbitrary set? If so, I can do 0 to 2 GiB.
2. Is there a way of saying a machine doesn’t
support indexing at all?
>> > If you want to go for an "x32" like mode, I think this
>> > is wrong approach.  The right approach would be to
>> > start from "-m64", and simply modify the pointer size
>> > to be 32 bits.
>> > This would work by setting POINTER_SIZE to 32, while
>> > leaving everything else like for -m64.
>  
>> That will generate 64-bit z/Arch instructions.
>> I wish to generate ESA/390 instructions.

> Why? AMODE64 exists only in z/Arch, so of course there
> will be z/Arch instructions available ...

For the same reason people constructed Babbage’s
invention, I wish to demonstrate the minor changes
that would have been required to the S/360 so that
we would never have arrived at a 31-bit black hole,
and we could have in fact had the perfect 32-bit
machine. Almost identical to the 31-bit machine.
A S/360+, a S/370+ and a S/390+. 

>> > We've thought about implementing this mode for Linux,
>> > but decided not to do it, since it would only provide
>> > marginal performance improvements, and has the drawback
>> > of being another new ABI that would be incompatible to
>> > the whole existing software ecosystem.
>> Shouldn’t the end user be able to decide this
>> for themselves?

> It's open source, of course everybode can decide what they
> want to work on themselves.  But we decide what we spend
> our own time on based on we think is useful ...

Sure.

>> No-one at all is interested in 32-bit mainframes?

> Not any more, at least not in Linux.  Linux is pretty much
> 64-bit only at this point.

I think z/OS is pretty much still 31-bit only,
as far as apps are concerned, right? I’d like to
bump that up to 32-bit.

BFN. Paul.

Re: s390 port

[Jakub Jelinek]

On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote:
> > This is not in one single place, but spread throughout the
> > compiler, both common code and back-end.  I do not think it will
> > be possible to get the compiler to generate correct code if
> > you do not specify the address size correctly.
> 1. Is there any way to put a constraint on index
> registers, to say that a particular machine can
> only index in the range of –512 to +512 or some
> other arbitrary set? If so, I can do 0 to 2 GiB.
> 2. Is there a way of saying a machine doesn’t
> support indexing at all?

There is a way to do that, but it isn't about changing a single or a couple
of spots, one needs to change a lot of *.md patterns, a lot of macros,
target hooks and as Ulrich said, most important is to use the right Pmode
which can differ from ptr_mode provided one e.g. defines ptr_extend pattern
etc.
Just look at the amount of work needed for the x32 or aarch64 ilp32 support,
and not just work spent one time on adding that support, but the continuous
amount of work on maintaining it.  The initial work is certainly a few
weeks if not months of work, then there needs to be somebody who regularly
tests gcc trunk and branches in such configuration so that it doesn't
bitrot, and not just that but somebody who actually fixes bugs in it.

If something doesn't fit into 2GB of address space, isn't it likely it won't
fit into 4GB of address space in a year or two?

	Jakub

Re: s390 port

[Paul Edwards]

>> > This is not in one single place, but spread throughout the
>> > compiler, both common code and back-end.  I do not think it will
>> > be possible to get the compiler to generate correct code if
>> > you do not specify the address size correctly.

>> 1. Is there any way to put a constraint on index
>> registers, to say that a particular machine can
>> only index in the range of –512 to +512 or some
>> other arbitrary set? If so, I can do 0 to 2 GiB.

>> 2. Is there a way of saying a machine doesn’t
>> support indexing at all?

> There is a way to do that, but it isn't about changing a single or a 
> couple
> of spots, one needs to change a lot of *.md patterns, a lot of macros,
> target hooks and as Ulrich said, most important is to use the right Pmode
> which can differ from ptr_mode provided one e.g. defines ptr_extend 
> pattern
> etc.

Pardon? All that is required just to put a constraint
on an index register? If a range of a machine is
limited to -512 to +512, it shouldn't be necessary
to change md patterns etc etc.

> Just look at the amount of work needed for the x32 or aarch64 ilp32 
> support,

That's different. That's because Intel stuffed up.
IBM didn't. IBM came within an ace of a perfect
architecture. It's as if Intel had created an x32
instead of an 80386 in 1986.

IBM got it almost right in the 1960s.

> and not just work spent one time on adding that support, but the 
> continuous
> amount of work on maintaining it.  The initial work is certainly a few
> weeks if not months of work,

I've been trying to figure out how to lift the 31-bit
restriction on mainframes since around 1987.

If I have to pay someone for 2 month of work, at
this stage, I'm willing to do that, but:

1. I would like it done on GCC 3.2.3 plus maybe
GCC 3.4.6.

2. How much will it cost in US$?

> then there needs to be somebody who regularly
> tests gcc trunk and branches in such configuration so that it doesn't
> bitrot, and not just that but somebody who actually fixes bugs in it.

I'll take responsibility for giving the GCC 3.X.X
releases the TLC they deserve. And I'll encourage
my daughter to maintain them after I've kicked
the bucket.

> If something doesn't fit into 2GB of address space,
> isn't it likely it won't fit into 4GB of address space
> in a year or two?

Nope. 2 GiB is already a shitload of memory. It only
takes something like 23 MB for GCC 3.2.3 to recompile
itself, and I think 60 MB for GCC 3.4.6 to recompile
itself. That's the heaviest real workload I do. A 4 GiB
limitation instead of 2 GiB makes it just that much
less likely I'll ever hit a real limit.

Someone told me that the only non-scientific application
they knew of that came close to hitting the 2 GiB limit
was IBM's C compiler. I doubt that IBM's C compiler
technology is evolving at such a rate that it only takes
1-2 years for them to subsequently hit 4 GiB. Quite
apart from the fact that I don't really trust that even
IBM C is hitting a 2 GiB limit for what GCC can do in
23 MiB. But it could be true - I'm not familiar with
compiler internals.

BFN. Paul.

Re: s390 port

[Paul Edwards]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Fri, 3 Sept 2021 at 20:12, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
wrote:

> "Paul Edwards" <mutazilah@gmail.com> wrote on 03.09.2021 13:35:10:
> > >  Specifically, if you try to run AMODE64 with Pmode equals
> > >  SImode, the compiler will not be aware that the hardware
> > >  uses the high 32 bits of base and index registers, and
> > >  will not necessarily keep them zero.
> > The compiler naturally keeps them zero. The
> > instructions that are used to load registers
> > do not pollute the high-order 32 bits.
>
> While this is true for most instructions, the compiler will not
> restrict itself to using only those.  (As just one obvious
> example, the compiler may use "lay" with a negative displacement,
> which will set the high bits of a GPR in AMODE64.)
>
> (And, b.t.w. not the -m31 DImode, which is a pair of 32-bit
> GPRs, but rather the -m64 DImode, which is a single 64-bit GPR.)
>

Hi all.

Turns out I have been asking the wrong question for several years.

I was going to generate a peephole (an idea from the author of
UDOS, now KinnowOS) to detect when a negative index was
being used, and force an addition instead of an index, when I
realized that it wasn't just literals that could use a negative
value.

That is when I realized that negative numbers were perfectly
valid/normal for indexing, and that it is the OS/hardware that
needs to adapt to this reality when transitioning from 32-bit
hardware to 64-bit hardware.

As such, I have updated z/PDOS-32 to use DAT to map the
4 GiB to 8 GiB region to 0 to 4 GiB, so that negative indexing
works fine.

You can download this from http://pdos.org (down the bottom).

So would it be possible now to update gcc to make -m32 and
-m31 and -m24 all work, as they all generate the exact same
code, regrardless of whether you are running as AM24 on
S/370, AM31 on S/390 or AM32 on Hercules/380 or AM64
with DAT set appropriately on z/Arch.

Thanks. Paul.

Re: i370 port

[Paul Edwards]

Let me ask a different question.

On GCC 3.2.3, does this sequence look correct:

./configure --target=i370-mvspdp --prefix=~/devel/mvscross --with-sysroot=~/devel/mvshead 
 --enable-languages=c
make
make install

./configure --build=x86_64-unknown-linux-gnu --host=i370-mvspdp --target=i370-mvspdp 
 --prefix=~/devel/mvshost --enable-languages=c --disable-nls
make


The first bit is working well - it is creating a cross-compiler.
But the second bit is not working well, on gcc 3.2.3 at
least. The sequence worked fine on gcc 3.4.6.

Thanks. Paul.

Re: i370 port

[Paul Edwards]

Hello all.

I have previously succeeded in getting configure to
work for gcc 3.4.6. Unfortunately gcc 3.4.6 is too
buggy to use and needs to wait for Dave Pitts or
someone to fix.

gcc 3.2.3 has no known bugs for the i370 target,
but it has not been done using "configure".

I am now trying to get gcc 3.2.3 to build via configure
using the same technique I used for gcc 3.4.6.

Some differences I found so far are as follows:

I needed to define the size of short etc which I
didn't need to do with 3.4.6:

export ac_cv_func_strncmp_works=yes
export ac_cv_c_bigendian=yes
export ac_cv_c_compile_endian=big-endian
export ac_cv_sizeof_short=2
export ac_cv_sizeof_int=4
export ac_cv_sizeof_long=4
export ac_cv_c_float_format='IBM 370 hex'

And "make", after this configure:

./configure --build=x86_64-unknown-linux-gnu --host=i370-mvspdp --target=i370-mvspdp 
 --prefix=/devel/mvshost --enable-languages=c --disable-nls

is failing here:

make[2]: Leaving directory 
`/home/users/k/ke/kerravon86/devel/gcc/x86_64-unknown
-linux-gnu/libiberty'
rm -f *~ Makefile config.status xhost-mkfrag TAGS multilib.out
rm -f config.log
rmdir testsuite 2>/dev/null
make[1]: [distclean] Error 1 (ignored)
make[1]: Leaving directory 
`/home/users/k/ke/kerravon86/devel/gcc/x86_64-unknown
-linux-gnu/libiberty'
loading cache ../config.cache
configure: error: can not find install-sh or install.sh in ./.. ././..
make: *** [configure-build-libiberty] Error 1

The file in question seems to exist:

~/devel/gcc>find . -name install-sh
./boehm-gc/install-sh
./install-sh
./fastjar/install-sh
~/devel/gcc>find . -name install.sh
~/devel/gcc>

and is executable.

Any suggestions?

Thanks. Paul.

Re: i370 port

[Ulrich Weigand]

Hi Paul,

> I put some debugging on here:
> 
>   op0 = XEXP (operands[0], 0);
>   if (GET_CODE (op0) == REG
>       || (GET_CODE (op0) == PLUS && GET_CODE (XEXP (op0, 0)) == REG
>     && GET_CODE (XEXP (op0, 1)) == CONST_INT
>     && (unsigned) INTVAL (XEXP (op0, 1)) < 4096))
>   {
>     op0 = operands[0];
>     fprintf(stderr, \"used as-is\n\");
>   }
>   else
>   {
>     op0 = replace_equiv_address (operands[0], copy_to_mode_reg (SImode, 
> op0));
>     fprintf(stderr, \"replaced\n\");
>   }
> 
> And I found out that op0 is already being "replaced". Shouldn't this
> replacement eliminate the index register and just have a base
> register, so that I don't need the hack further down?

Well, sure, but this code is just the expander.  If you check the
RTL dumps, you'll notice that after the expand step, there will
indeed be just a single base register.

The problem is that RTL optimization steps *after* expand may
modify the generated RTX.  In particular reload will do so, and
it will be guided by the constraints to tell it which modifications
are allowed for this insn.  If the actual insn pattern (not the
expander) has a generic "m" constraint, reload will feel free to
replace the address with any generally valid address pattern for
the machine, including those that use an index registers, if it
considers this replacement profitable.

This is exactly the reason why you need a constraint letter
that accepts only addresses without index register, instead of
just using plain "m".

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi Ulrich.

A further question.

I put some debugging on here:

  op0 = XEXP (operands[0], 0);
  if (GET_CODE (op0) == REG
      || (GET_CODE (op0) == PLUS && GET_CODE (XEXP (op0, 0)) == REG
    && GET_CODE (XEXP (op0, 1)) == CONST_INT
    && (unsigned) INTVAL (XEXP (op0, 1)) < 4096))
  {
    op0 = operands[0];
    fprintf(stderr, \"used as-is\n\");
  }
  else
  {
    op0 = replace_equiv_address (operands[0], copy_to_mode_reg (SImode, 
op0));
    fprintf(stderr, \"replaced\n\");
  }

And I found out that op0 is already being "replaced". Shouldn't this
replacement eliminate the index register and just have a base
register, so that I don't need the hack further down?

Thanks.  Paul.

Re: i370 port

[Paul Edwards]

> Ah, yes.  The problem is that reload assumes any valid address
> can be loaded into a register with a single instruction, and
> it will thus simply generate such instructions unconditionally
> -- and if the target then doesn't actually provide such a pattern,
> it will fail with "unrecognizable insn".

Hi Ulrich. Thanks for your reply.

This approach seems to be quite complicated. What do you think
about the option of NOT adding this (which triggers off errors I
hadn't seen before):

#define EXTRA_MEMORY_CONSTRAINT(C, STR) \
   ((C) == 'S')

and instead making a change similar to what I have already put in
under "hack" below? Is that legitimate?

;
; movstrsi instruction pattern(s).
; block must be less than 16M (24 bits) in length

(define_expand "movstrsi"
  [(set (match_operand:BLK 0 "general_operand" "")
        (match_operand:BLK 1 "general_operand" ""))
   (use (match_operand:SI  2 "general_operand" ""))
   (match_operand 3 "" "")]
   ""
   "
{
  rtx op0, op1;

  op0 = XEXP (operands[0], 0);
  if (GET_CODE (op0) == REG
      || (GET_CODE (op0) == PLUS && GET_CODE (XEXP (op0, 0)) == REG
          && GET_CODE (XEXP (op0, 1)) == CONST_INT
          && (unsigned) INTVAL (XEXP (op0, 1)) < 4096))
    op0 = operands[0];
  else
    op0 = replace_equiv_address (operands[0], copy_to_mode_reg (SImode, 
op0));

  op1 = XEXP (operands[1], 0);
  if (GET_CODE (op1) == REG
      || (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1, 0)) == REG
          && GET_CODE (XEXP (op1, 1)) == CONST_INT
          && (unsigned) INTVAL (XEXP (op1, 1)) < 4096))
    op1 = operands[1];
  else
    op1 = replace_equiv_address (operands[1], copy_to_mode_reg (SImode, 
op1));

  /* first line is a hack - if target address involves two registers,
     we can't use an MVC, even if the length to move is less than 256,
     because MVC takes an S parameter. I'm unsure of the best way to
     distinguish a two-register target. */
  if (!((GET_CODE(op0) == MEM) && REG_P(XEXP(op0,0))) &&
      GET_CODE (operands[2]) == CONST_INT && INTVAL (operands[2]) < 256)
    emit_insn (gen_rtx_PARALLEL (VOIDmode,
                        gen_rtvec (2,
                                   gen_rtx_SET (VOIDmode, op0, op1),
                                   gen_rtx_USE (VOIDmode, operands[2]))));

  else
    {
        /* implementation provided by  Richard Henderson <rth@cygnus.com> */
        rtx reg1 = gen_reg_rtx (DImode);
        rtx reg2 = gen_reg_rtx (DImode);
        rtx mem1 = operands[0];
        rtx mem2 = operands[1];
        rtx len = operands[2];
        if (!CONSTANT_P (len))
          len = force_reg (SImode, len);

        /* Load up the address+length pairs.  */
        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
                        force_operand (XEXP (mem1, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)), len);

        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
                        force_operand (XEXP (mem2, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)), len);

        /* Copy! */
        emit_insn (gen_movstrsi_1 (reg1, reg2));
    }
  DONE;
}")


Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> I've managed to isolate the problem to a small test program.
> 
> Any suggestions on how to debug this?

> bug27.c:28: error: unrecognizable insn:
> (insn 116 34 35 2 (set (reg:SI 5 5)
>         (plus:SI (plus:SI (reg:SI 2 2 [orig:54 i ] [54])
>                 (reg/f:SI 13 13))
>             (const_int 104 [0x68]))) -1 (nil)
>     (nil))

Ah, yes.  The problem is that reload assumes any valid address
can be loaded into a register with a single instruction, and
it will thus simply generate such instructions unconditionally
-- and if the target then doesn't actually provide such a pattern,
it will fail with "unrecognizable insn".

The "LA" pattern you showed accepts only "(certain) single register
+ constant", which doesn't match the pattern above "register +
register + constant".

The difficulty is now that while "LA" *does* actually support adding
base + index + displacement, you cannot simply add a pattern 
expressing that, because LA only does a 31-bit add, so it must only
be used to add addresses, not when adding general 32-bit SImode
values.

The way I handle this in the s390 port is to provide a "forced"
LA instruction pattern using a magic marker that prevents the
pattern from being matched by regular instructions, and then add
a secondary reload to emit that "forced" LA when reload needs
to load an address.

Here's the relevant snippets from the 3.4 s390 back-end:

/* We need a secondary reload when loading a PLUS which is
   not a valid operand for LOAD ADDRESS.  */
#define SECONDARY_INPUT_RELOAD_CLASS(CLASS, MODE, IN)   \
  s390_secondary_input_reload_class ((CLASS), (MODE), (IN))

(define_insn "*la_31"
  [(set (match_operand:SI 0 "register_operand" "=d,d")
        (match_operand:QI 1 "address_operand" "U,W"))]
  "!TARGET_64BIT && legitimate_la_operand_p (operands[1])"
  "@
   la\t%0,%a1
   lay\t%0,%a1"
  [(set_attr "op_type"  "RX,RXY")
   (set_attr "type"     "la")])

(define_insn "force_la_31"
  [(set (match_operand:SI 0 "register_operand" "=d,d")
        (match_operand:QI 1 "address_operand" "U,W"))
   (use (const_int 0))]
  "!TARGET_64BIT"
  "@
   la\t%0,%a1
   lay\t%0,%a1"
  [(set_attr "op_type"  "RX")
   (set_attr "type"     "la")])

(define_expand "reload_insi"
  [(parallel [(match_operand:SI 0 "register_operand" "=a")
              (match_operand:SI 1 "s390_plus_operand" "")
              (match_operand:SI 2 "register_operand" "=&a")])]
  "!TARGET_64BIT"
{
  s390_expand_plus_operand (operands[0], operands[1], operands[2]);
  DONE;
})

(and of course the functions in s390.c called by these.)

You ought to be able to do something similar in your backend ...


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> I have reviewed the 'W' code in PRINT_OPERAND:
> 
> else if (CODE == 'W')
>   {
>     /* hand-built sign-extension of signed 32-bit to 64-bit */
>     mvs_page_lit += 8;
>     if (0 <=  INTVAL (XV)) {
>        fprintf (FILE, "=XL8'00000000");
>     } else {
>        fprintf (FILE, "=XL8'FFFFFFFF");
>     }
>     fprintf (FILE, "%08X'", INTVAL (XV));
>   }
> 
> and it looks to me like it is already correct. If movdi is given a
> const_int as a parameter, then sign-extending to 64-bit is
> exactly what needs to happen, isn't it?
> 
> I'm only expecting to compile programs as 32-bit, so I'm not
> expecting more than 32-bit integers. The IFOX assembler
> won't do more than that. In case that's the issue.

Well, even on 32-bit you may get 64-bit integer constants,
e.g. via the "long long" data type:

  long long x = 0x123456789abcdefLL;

However, the real question in your case is whether those are
represented as CONST_INT.  This is only true if HOST_WIDE_INT
is a 64-bit type; otherwise, such constants would be represented
as a CONST_DOUBLE.

Whether or not HOST_WIDE_INT is a 64-bit type now depends on
which *host* you're building GCC as a cross-compiler on.  If
you only ever support 32-bit hosts, then HOST_WIDE_INT will
always be a 32-bit type, and the code above should be fine.

If you want to support 64-bit hosts as well, however, you
will need to handle 64-bit CONST_INT values too.

> But regardless I don't know how to make this code:
> 
> mvs_check_page (0, 6, 8);
> return \"MVC^I%O0(8,%R0),%1\";
> 
> make use of that 'W' operand.
> 
> Do I change that %1 to %W1 perhaps?

Yes, exactly.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

I've managed to isolate the problem to a small test program.

Any suggestions on how to debug this?

Thanks.  Paul.




C:\devel\gcc\gcc>type bug27.c
/* This program demonstrates a bug in a modification to GCC 3.4.6 */
/* It generates the below error when compiled with -O2 */

#if 0
bug27.c: In function `foo':
bug27.c:28: error: unrecognizable insn:
(insn 116 34 35 2 (set (reg:SI 5 5)
        (plus:SI (plus:SI (reg:SI 2 2 [orig:54 i ] [54])
                (reg/f:SI 13 13))
            (const_int 104 [0x68]))) -1 (nil)
    (nil))
bug27.c:28: internal compiler error: in ZZZ_680, at recog.c:2083
#endif

void foo(int c)
{
    int x[3];
    int y[3];
    int i;

    for (i = 0; i < 2; i++)
    {
        if (c == 1) x[i] &= y[i];
        else if (c == 2) x[i] |= y[i];
    }

    return;
}

C:\devel\gcc\gcc>





-----Original Message----- 
From: Paul Edwards
Sent: Friday, April 06, 2012 3:50 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

I have made this change:

C:\devel\gcc\gcc\config\i370>cvs diff -c -r 1.23 i370.md
Index: i370.md
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.23
retrieving revision 1.24
diff -c -r1.23 -r1.24
*** i370.md     6 Apr 2012 03:57:08 -0000       1.23
--- i370.md     6 Apr 2012 04:03:21 -0000       1.24
***************
*** 843,848 ****
--- 843,853 ----
        /*return \"STM  %1,%N1,%0\"; */
        return \"ST     %1,%0\;ST       %N1,4+%0\";
      }
+   if (GET_CODE (operands[1]) == CONST_INT)
+     {
+       mvs_check_page (0, 6, 8);
+       return \"MVC    %O0(8,%R0),%W1\";
+     }
    mvs_check_page (0, 6, 8);
    return \"MVC        %O0(8,%R0),%1\";
  }"

C:\devel\gcc\gcc\config\i370>


And it has had a good effect:

diff old/cpplib.s new/cpplib.s
1670c1670
<          MVC   120(8,13),=F'0'
---
>          MVC   120(8,13),=XL8'0000000000000000'
1796c1796
<          MVC   120(8,13),=F'0'
---
>          MVC   120(8,13),=XL8'0000000000000000'




However, I'm still stuck.  Because when I make this change:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.17 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.17
retrieving revision 1.18
diff -r1.17 -r1.18
599a600,602
> #define EXTRA_MEMORY_CONSTRAINT(C, STR) \
>   ((C) == 'S')
>

It triggers off a problem with plus:SI

C:\devel\gcc\gcc>stdcompm global.c

C:\devel\gcc\gcc>gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC -DPUREISO
-
I ../../pdos/pdpclib -I . -I config/i370 -I ../include         global.c
global.c: In function `find_reg':
global.c:1325: error: unrecognizable insn:
(insn 2432 130 131 12 (set (reg:SI 15 15)
        (plus:SI (plus:SI (reg:SI 4 4 [orig:82 allocno ] [82])
                (reg:SI 3 3 [87]))
            (const_int 44 [0x2c]))) -1 (nil)
    (nil))
global.c:1325: internal compiler error: in ZZZ_680, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.

C:\devel\gcc\gcc>


Seems to be a problem when adding very small const_ints (in
the above case, 44) that can fit into a LA.  I tried to isolate
which plus:SI rule was causing the problem by commenting out these:

;
; addsi3 instruction pattern(s).
;
; The following insn is used when it is known that operand one is an
address,
; frame, stack or argument pointer, and operand two is a constant that is
; small enough to fit in the displacement field.
; Notice that we can't allow the frame pointer to used as a normal register
; because of this insn.
;

;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%a")
;^I^I (match_operand:SI 2 "immediate_operand" "J")))]
;  "((REGNO (operands[1]) == FRAME_POINTER_REGNUM || REGNO (operands[1]) ==
ARG$
;  "*
;{
;  check_label_emit ();
;  CC_STATUS_INIT;  /* add assumes CC but LA doesn't set CC */
;  mvs_check_page (0, 4, 0);
;  return \"LA^I%0,%c2(,%1)\";
;}"
;   [(set_attr "length" "4")]
;)

;; The CC status bits for the arithmetic instructions are handled
;; in the NOTICE_UPDATE_CC macro (yeah???) and so they do not need
;; to be set below.  They only need to be invalidated if *not* set
;; (e.g. by BCTR) ... yeah I think that's right ...
;;

;(define_insn "addsi3"
;  [(set (match_operand:SI 0 "nonimmediate_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%0")
;^I^I (match_operand:SI 2 "general_operand" "g")))]
;  ""
;  "*
;{
;  check_label_emit ();
;  if (REG_P (operands[2]))
;    {
;      mvs_check_page (0, 2, 0);
;      return \"AR^I%0,%2\";
;    }
;  if (GET_CODE (operands[2]) == CONST_INT)
;    {
;      if (INTVAL (operands[2]) == -1)
;^I{
;          CC_STATUS_INIT;  /* add assumes CC but BCTR doesn't set CC */
;^I  mvs_check_page (0, 2, 0);
;^I  return \"BCTR^I%0,0\";
;^I}
;    }
;  mvs_check_page (0, 4, 0);
;  return \"A^I%0,%2\";
;}"
;   [(set_attr "length" "4")]
;)


But that seemed to invoke some sort of bug in the main compiler:

C:\devel\gcc\gcc>stdcompm alias.c

C:\devel\gcc\gcc>gdb --args
gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC
-DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I ../include
alias.
c
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program:
/cygdrive/c/devel/gcc/gcc/gccmvs.exe -DUSE_MEMMGR -Os -S -DHAV
E_CONFIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
../in
clude alias.c
Error: dll starting at 0x76901000 not found.
Error: dll starting at 0x761f1000 not found.
Error: dll starting at 0x76901000 not found.
Error: dll starting at 0x765f1000 not found.
Loaded symbols for /cygdrive/c/Windows/system32/ntdll.dll
Loaded symbols for /cygdrive/c/Windows/syswow64/kernel32.dll
Loaded symbols for /cygdrive/c/Windows/syswow64/KernelBase.dll

Program received signal SIGSEGV, Segmentation fault.
0x005fca41 in discover_flags_reg () at regmove.c:174
174       if (GET_CODE (tmp) == SET)
(gdb) where
#0  0x005fca41 in discover_flags_reg () at regmove.c:174
#1  0x005fdfd7 in regmove_optimize (f=0x1aaecc0, nregs=29,
    regmove_dump_file=0x0) at regmove.c:1056
#2  0x0064d6bc in rest_of_handle_regmove (decl=0x177a000, insns=0x1aaecc0)
    at toplev.c:2438
#3  0x0064f1af in ZZZ_1833 (decl=0x177a000) at toplev.c:3412
#4  0x00656061 in tree_rest_of_compilation (fndecl=0x177a000,
nested_p=false)
    at tree-optimize.c:168
#5  0x0043e6ec in c_expand_body_1 (fndecl=0x177a000, nested_p=0)
    at c-decl.c:6190
#6  0x0043e835 in ZZZ_331 (fndecl=0x177a000) at c-decl.c:6222
#7  0x00487dee in cgraph_expand_function (node=0x177ec3c) at
cgraphunit.c:538
#8  0x00489e7e in cgraph_expand_all_functions () at cgraphunit.c:1542
#9  0x0048a046 in cgraph_optimize () at cgraphunit.c:1607
#10 0x00447d75 in ZZZ_345 () at c-objc-common.c:240
#11 0x0044664b in ZZZ_708 () at c-lang.c:185
#12 0x0044947f in ZZZ_318 (set_yydebug=0) at c-opts.c:1270
#13 0x0064cd88 in compile_file () at toplev.c:1848
#14 0x00650f5a in do_compile () at toplev.c:4695
#15 0x00650ff5 in toplev_main (argc=26, argv=0xcc583c) at toplev.c:4735
#16 0x0054df47 in execute () at gcc.c:2785
#17 0x00551c59 in do_spec (
    spec=0x6a997c "%{E|M|MM:%(trad_capable_cpp) %(cpp_options)
%(cpp_debug_optio
ns)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer
supports -tra
ditional without -E} %{save-temps|traditional-cpp|no-integr"...)
    at gcc.c:4265
#18 0x00556a1b in main (argc=16, argv=0x6e6920) at gcc.c:6437
(gdb)


/* Determine if the pattern generated by add_optab has a clobber,
   such as might be issued for a flags hard register.  To make the
   code elsewhere simpler, we handle cc0 in this same framework.

   Return the register if one was discovered.  Return NULL_RTX if
   if no flags were found.  Return pc_rtx if we got confused.  */

static rtx
discover_flags_reg (void)
{
  rtx tmp;
  tmp = gen_rtx_REG (word_mode, 10000);
  tmp = gen_add3_insn (tmp, tmp, GEN_INT (2));

  /* If we get something that isn't a simple set, or a
     [(set ..) (clobber ..)], this whole function will go wrong.  */
  if (GET_CODE (tmp) == SET)



I tried commenting out different plus:SI rules, but that also
met with a crash in the main compiler.

So I don't know which plus:SI is causing the problem, and
it seems very strange that the extra memory constraint
triggers off the problem.

Any ideas?

Thanks.  Paul.






-----Original Message----- 
From: Paul Edwards
Sent: Thursday, April 05, 2012 11:31 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Hi Ulrich.

I'm getting back to this after a long hiatus.

I have reviewed the 'W' code in PRINT_OPERAND:

else if (CODE == 'W')
  {
    /* hand-built sign-extension of signed 32-bit to 64-bit */
    mvs_page_lit += 8;
    if (0 <=  INTVAL (XV)) {
       fprintf (FILE, "=XL8'00000000");
    } else {
       fprintf (FILE, "=XL8'FFFFFFFF");
    }
    fprintf (FILE, "%08X'", INTVAL (XV));
  }

and it looks to me like it is already correct. If movdi is given a
const_int as a parameter, then sign-extending to 64-bit is
exactly what needs to happen, isn't it?

I'm only expecting to compile programs as 32-bit, so I'm not
expecting more than 32-bit integers. The IFOX assembler
won't do more than that. In case that's the issue.

But regardless I don't know how to make this code:

mvs_check_page (0, 6, 8);
return \"MVC^I%O0(8,%R0),%1\";

make use of that 'W' operand.

Do I change that %1 to %W1 perhaps?

I'll give that a try tomorrow.

Thanks.  Paul.





-----Original Message----- 
From: Ulrich Weigand
Sent: Monday, August 22, 2011 10:22 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:

>   if (operands[1] == const0_rtx)
>   {
>     CC_STATUS_INIT;
>     mvs_check_page (0, 6, 8);
>     return \"MVC    %O0(8,%R0),=XL8'00'\";
>   }
>   mvs_check_page (0, 6, 8);
>   return \"MVC    %O0(8,%R0),%1\";
> }"
>    [(set_attr "length" "8")]
> )
>
> forces it to use XL8'00' instead of the default F'0' and that
> seems to work.  Does that seem like a proper solution to
> you?

Well, there isn't really anything special about const0_rtx.
*Any* CONST_INT that shows up as second operand to the movdi
pattern must be emitted into an 8 byte literal at this point.

You can do that inline; but the more usual way would be to
define an operand print format that encodes the fact that
a 64-bit operand is requested.

In fact, looking at the i370.h PRINT_OPERAND, there already
seems to be such a format: 'W'.  (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit.  But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com 

Re: i370 port

[Paul Edwards]

I have made this change:

C:\devel\gcc\gcc\config\i370>cvs diff -c -r 1.23 i370.md
Index: i370.md
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.23
retrieving revision 1.24
diff -c -r1.23 -r1.24
*** i370.md     6 Apr 2012 03:57:08 -0000       1.23
--- i370.md     6 Apr 2012 04:03:21 -0000       1.24
***************
*** 843,848 ****
--- 843,853 ----
        /*return \"STM  %1,%N1,%0\"; */
        return \"ST     %1,%0\;ST       %N1,4+%0\";
      }
+   if (GET_CODE (operands[1]) == CONST_INT)
+     {
+       mvs_check_page (0, 6, 8);
+       return \"MVC    %O0(8,%R0),%W1\";
+     }
    mvs_check_page (0, 6, 8);
    return \"MVC        %O0(8,%R0),%1\";
  }"

C:\devel\gcc\gcc\config\i370>


And it has had a good effect:

diff old/cpplib.s new/cpplib.s
1670c1670
<          MVC   120(8,13),=F'0'
---
>          MVC   120(8,13),=XL8'0000000000000000'
1796c1796
<          MVC   120(8,13),=F'0'
---
>          MVC   120(8,13),=XL8'0000000000000000'




However, I'm still stuck.  Because when I make this change:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.17 i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.17
retrieving revision 1.18
diff -r1.17 -r1.18
599a600,602
> #define EXTRA_MEMORY_CONSTRAINT(C, STR) \
>   ((C) == 'S')
>

It triggers off a problem with plus:SI

C:\devel\gcc\gcc>stdcompm global.c

C:\devel\gcc\gcc>gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC -DPUREISO 
 -
I ../../pdos/pdpclib -I . -I config/i370 -I ../include         global.c
global.c: In function `find_reg':
global.c:1325: error: unrecognizable insn:
(insn 2432 130 131 12 (set (reg:SI 15 15)
        (plus:SI (plus:SI (reg:SI 4 4 [orig:82 allocno ] [82])
                (reg:SI 3 3 [87]))
            (const_int 44 [0x2c]))) -1 (nil)
    (nil))
global.c:1325: internal compiler error: in ZZZ_680, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.

C:\devel\gcc\gcc>


Seems to be a problem when adding very small const_ints (in
the above case, 44) that can fit into a LA.  I tried to isolate
which plus:SI rule was causing the problem by commenting out these:

;
; addsi3 instruction pattern(s).
;
; The following insn is used when it is known that operand one is an 
address,
; frame, stack or argument pointer, and operand two is a constant that is
; small enough to fit in the displacement field.
; Notice that we can't allow the frame pointer to used as a normal register
; because of this insn.
;

;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%a")
;^I^I (match_operand:SI 2 "immediate_operand" "J")))]
;  "((REGNO (operands[1]) == FRAME_POINTER_REGNUM || REGNO (operands[1]) == 
ARG$
;  "*
;{
;  check_label_emit ();
;  CC_STATUS_INIT;  /* add assumes CC but LA doesn't set CC */
;  mvs_check_page (0, 4, 0);
;  return \"LA^I%0,%c2(,%1)\";
;}"
;   [(set_attr "length" "4")]
;)

;; The CC status bits for the arithmetic instructions are handled
;; in the NOTICE_UPDATE_CC macro (yeah???) and so they do not need
;; to be set below.  They only need to be invalidated if *not* set
;; (e.g. by BCTR) ... yeah I think that's right ...
;;

;(define_insn "addsi3"
;  [(set (match_operand:SI 0 "nonimmediate_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%0")
;^I^I (match_operand:SI 2 "general_operand" "g")))]
;  ""
;  "*
;{
;  check_label_emit ();
;  if (REG_P (operands[2]))
;    {
;      mvs_check_page (0, 2, 0);
;      return \"AR^I%0,%2\";
;    }
;  if (GET_CODE (operands[2]) == CONST_INT)
;    {
;      if (INTVAL (operands[2]) == -1)
;^I{
;          CC_STATUS_INIT;  /* add assumes CC but BCTR doesn't set CC */
;^I  mvs_check_page (0, 2, 0);
;^I  return \"BCTR^I%0,0\";
;^I}
;    }
;  mvs_check_page (0, 4, 0);
;  return \"A^I%0,%2\";
;}"
;   [(set_attr "length" "4")]
;)


But that seemed to invoke some sort of bug in the main compiler:

C:\devel\gcc\gcc>stdcompm alias.c

C:\devel\gcc\gcc>gdb --args 
gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC
-DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I ../include 
alias.
c
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: 
/cygdrive/c/devel/gcc/gcc/gccmvs.exe -DUSE_MEMMGR -Os -S -DHAV
E_CONFIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../in
clude alias.c
Error: dll starting at 0x76901000 not found.
Error: dll starting at 0x761f1000 not found.
Error: dll starting at 0x76901000 not found.
Error: dll starting at 0x765f1000 not found.
Loaded symbols for /cygdrive/c/Windows/system32/ntdll.dll
Loaded symbols for /cygdrive/c/Windows/syswow64/kernel32.dll
Loaded symbols for /cygdrive/c/Windows/syswow64/KernelBase.dll

Program received signal SIGSEGV, Segmentation fault.
0x005fca41 in discover_flags_reg () at regmove.c:174
174       if (GET_CODE (tmp) == SET)
(gdb) where
#0  0x005fca41 in discover_flags_reg () at regmove.c:174
#1  0x005fdfd7 in regmove_optimize (f=0x1aaecc0, nregs=29,
    regmove_dump_file=0x0) at regmove.c:1056
#2  0x0064d6bc in rest_of_handle_regmove (decl=0x177a000, insns=0x1aaecc0)
    at toplev.c:2438
#3  0x0064f1af in ZZZ_1833 (decl=0x177a000) at toplev.c:3412
#4  0x00656061 in tree_rest_of_compilation (fndecl=0x177a000, 
nested_p=false)
    at tree-optimize.c:168
#5  0x0043e6ec in c_expand_body_1 (fndecl=0x177a000, nested_p=0)
    at c-decl.c:6190
#6  0x0043e835 in ZZZ_331 (fndecl=0x177a000) at c-decl.c:6222
#7  0x00487dee in cgraph_expand_function (node=0x177ec3c) at 
cgraphunit.c:538
#8  0x00489e7e in cgraph_expand_all_functions () at cgraphunit.c:1542
#9  0x0048a046 in cgraph_optimize () at cgraphunit.c:1607
#10 0x00447d75 in ZZZ_345 () at c-objc-common.c:240
#11 0x0044664b in ZZZ_708 () at c-lang.c:185
#12 0x0044947f in ZZZ_318 (set_yydebug=0) at c-opts.c:1270
#13 0x0064cd88 in compile_file () at toplev.c:1848
#14 0x00650f5a in do_compile () at toplev.c:4695
#15 0x00650ff5 in toplev_main (argc=26, argv=0xcc583c) at toplev.c:4735
#16 0x0054df47 in execute () at gcc.c:2785
#17 0x00551c59 in do_spec (
    spec=0x6a997c "%{E|M|MM:%(trad_capable_cpp) %(cpp_options) 
%(cpp_debug_optio
ns)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer 
supports -tra
ditional without -E} %{save-temps|traditional-cpp|no-integr"...)
    at gcc.c:4265
#18 0x00556a1b in main (argc=16, argv=0x6e6920) at gcc.c:6437
(gdb)


/* Determine if the pattern generated by add_optab has a clobber,
   such as might be issued for a flags hard register.  To make the
   code elsewhere simpler, we handle cc0 in this same framework.

   Return the register if one was discovered.  Return NULL_RTX if
   if no flags were found.  Return pc_rtx if we got confused.  */

static rtx
discover_flags_reg (void)
{
  rtx tmp;
  tmp = gen_rtx_REG (word_mode, 10000);
  tmp = gen_add3_insn (tmp, tmp, GEN_INT (2));

  /* If we get something that isn't a simple set, or a
     [(set ..) (clobber ..)], this whole function will go wrong.  */
  if (GET_CODE (tmp) == SET)



I tried commenting out different plus:SI rules, but that also
met with a crash in the main compiler.

So I don't know which plus:SI is causing the problem, and
it seems very strange that the extra memory constraint
triggers off the problem.

Any ideas?

Thanks.  Paul.






-----Original Message----- 
From: Paul Edwards
Sent: Thursday, April 05, 2012 11:31 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Hi Ulrich.

I'm getting back to this after a long hiatus.

I have reviewed the 'W' code in PRINT_OPERAND:

else if (CODE == 'W')
  {
    /* hand-built sign-extension of signed 32-bit to 64-bit */
    mvs_page_lit += 8;
    if (0 <=  INTVAL (XV)) {
       fprintf (FILE, "=XL8'00000000");
    } else {
       fprintf (FILE, "=XL8'FFFFFFFF");
    }
    fprintf (FILE, "%08X'", INTVAL (XV));
  }

and it looks to me like it is already correct. If movdi is given a
const_int as a parameter, then sign-extending to 64-bit is
exactly what needs to happen, isn't it?

I'm only expecting to compile programs as 32-bit, so I'm not
expecting more than 32-bit integers. The IFOX assembler
won't do more than that. In case that's the issue.

But regardless I don't know how to make this code:

mvs_check_page (0, 6, 8);
return \"MVC^I%O0(8,%R0),%1\";

make use of that 'W' operand.

Do I change that %1 to %W1 perhaps?

I'll give that a try tomorrow.

Thanks.  Paul.





-----Original Message----- 
From: Ulrich Weigand
Sent: Monday, August 22, 2011 10:22 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:

>   if (operands[1] == const0_rtx)
>   {
>     CC_STATUS_INIT;
>     mvs_check_page (0, 6, 8);
>     return \"MVC    %O0(8,%R0),=XL8'00'\";
>   }
>   mvs_check_page (0, 6, 8);
>   return \"MVC    %O0(8,%R0),%1\";
> }"
>    [(set_attr "length" "8")]
> )
>
> forces it to use XL8'00' instead of the default F'0' and that
> seems to work.  Does that seem like a proper solution to
> you?

Well, there isn't really anything special about const0_rtx.
*Any* CONST_INT that shows up as second operand to the movdi
pattern must be emitted into an 8 byte literal at this point.

You can do that inline; but the more usual way would be to
define an operand print format that encodes the fact that
a 64-bit operand is requested.

In fact, looking at the i370.h PRINT_OPERAND, there already
seems to be such a format: 'W'.  (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit.  But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com 

Re: i370 port

[Paul Edwards]

Hi Ulrich.

I'm getting back to this after a long hiatus.

I have reviewed the 'W' code in PRINT_OPERAND:

else if (CODE == 'W')
  {
    /* hand-built sign-extension of signed 32-bit to 64-bit */
    mvs_page_lit += 8;
    if (0 <=  INTVAL (XV)) {
       fprintf (FILE, "=XL8'00000000");
    } else {
       fprintf (FILE, "=XL8'FFFFFFFF");
    }
    fprintf (FILE, "%08X'", INTVAL (XV));
  }

and it looks to me like it is already correct. If movdi is given a
const_int as a parameter, then sign-extending to 64-bit is
exactly what needs to happen, isn't it?

I'm only expecting to compile programs as 32-bit, so I'm not
expecting more than 32-bit integers. The IFOX assembler
won't do more than that. In case that's the issue.

But regardless I don't know how to make this code:

mvs_check_page (0, 6, 8);
return \"MVC^I%O0(8,%R0),%1\";

make use of that 'W' operand.

Do I change that %1 to %W1 perhaps?

I'll give that a try tomorrow.

Thanks.  Paul.





-----Original Message----- 
From: Ulrich Weigand 
Sent: Monday, August 22, 2011 10:22 PM 
To: Paul Edwards 
Cc: gcc@gcc.gnu.org 
Subject: Re: i370 port 

Paul Edwards wrote:

>   if (operands[1] == const0_rtx)
>   {
>     CC_STATUS_INIT;
>     mvs_check_page (0, 6, 8);
>     return \"MVC    %O0(8,%R0),=XL8'00'\";
>   }
>   mvs_check_page (0, 6, 8);
>   return \"MVC    %O0(8,%R0),%1\";
> }"
>    [(set_attr "length" "8")]
> )
> 
> forces it to use XL8'00' instead of the default F'0' and that
> seems to work.  Does that seem like a proper solution to
> you?

Well, there isn't really anything special about const0_rtx.
*Any* CONST_INT that shows up as second operand to the movdi
pattern must be emitted into an 8 byte literal at this point.

You can do that inline; but the more usual way would be to
define an operand print format that encodes the fact that
a 64-bit operand is requested.

In fact, looking at the i370.h PRINT_OPERAND, there already
seems to be such a format: 'W'.  (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit.  But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

>   if (operands[1] == const0_rtx)
>   {
>     CC_STATUS_INIT;
>     mvs_check_page (0, 6, 8);
>     return \"MVC    %O0(8,%R0),=XL8'00'\";
>   }
>   mvs_check_page (0, 6, 8);
>   return \"MVC    %O0(8,%R0),%1\";
> }"
>    [(set_attr "length" "8")]
> )
> 
> forces it to use XL8'00' instead of the default F'0' and that
> seems to work.  Does that seem like a proper solution to
> you?

Well, there isn't really anything special about const0_rtx.
*Any* CONST_INT that shows up as second operand to the movdi
pattern must be emitted into an 8 byte literal at this point.

You can do that inline; but the more usual way would be to
define an operand print format that encodes the fact that
a 64-bit operand is requested.

In fact, looking at the i370.h PRINT_OPERAND, there already
seems to be such a format: 'W'.  (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit.  But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Adding this code:

C:\devel\gcc\gcc\config\i370>cvs diff i370.md
Index: i370.md
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.21
diff -r1.21 i370.md
845a846,851
>   if (operands[1] == const0_rtx)
>   {
>     CC_STATUS_INIT;
>     mvs_check_page (0, 6, 8);
>     return \"MVC      %O0(8,%R0),=XL8'00'\";
>   }

to the i370.md definition:

;
; movdi instruction pattern(s).
;

(define_insn ""
  [(set (match_operand:DI 0 "nonimmediate_operand" "=d,m,S")
        (match_operand:DI 1 "general_operand" "g,d,SF"))]
;;  [(set (match_operand:DI 0 "r_or_s_operand" "=dS,m")
;;        (match_operand:DI 1 "r_or_s_operand" "diS*fF,d*fF"))]
  "TARGET_CHAR_INSTRUCTIONS"
  "*
{
  check_label_emit ();
  if (REG_P (operands[0]))
    {
      if (FP_REG_P (operands[1]))
    {
      mvs_check_page (0, 8, 0);
      return \"STD    %1,\" CONVLO \"(,13)\;LM    %0,%N0,\" CONVLO \"(13)\";
    }
      if (REG_P (operands[1]))
    {
      mvs_check_page (0, 4, 0);
      return \"LR    %0,%1\;LR    %N0,%N1\";
    }
      if (operands[1] == const0_rtx)
    {
      CC_STATUS_INIT;
      mvs_check_page (0, 4, 0);
      return \"SLR    %0,%0\;SLR    %N0,%N0\";
    }
      if (GET_CODE (operands[1]) == CONST_INT
        && (unsigned) INTVAL (operands[1]) < 4096)
    {
      CC_STATUS_INIT;
      mvs_check_page (0, 6, 0);
      return \"SLR    %0,%0\;LA    %N0,%c1(0,0)\";
    }
      if (GET_CODE (operands[1]) == CONST_INT)
    {
      CC_STATUS_SET (operands[0], operands[1]);
      mvs_check_page (0, 8, 0);
      return \"L    %0,%1\;SRDA    %0,32\";
    }
      if (GET_CODE (operands[1]) == CONST_DOUBLE)
    {
      mvs_check_page (0, 6, 8);
      return \"LM    %0,%N0,%1\";
    }
      mvs_check_page (0, 4, 0);
      /*return \"LM    %0,%N0,%1\";*/
      return \"L    %0,%1\;L    %N0,4+%1\";
    }
  else if (FP_REG_P (operands[1]))
    {
      mvs_check_page (0, 4, 0);
      return \"STD    %1,%0\";
    }
  else if (REG_P (operands[1]))
    {
      mvs_check_page (0, 4, 0);
      /*return \"STM    %1,%N1,%0\"; */
      return \"ST    %1,%0\;ST    %N1,4+%0\";
    }
  if (operands[1] == const0_rtx)
  {
    CC_STATUS_INIT;
    mvs_check_page (0, 6, 8);
    return \"MVC    %O0(8,%R0),=XL8'00'\";
  }
  mvs_check_page (0, 6, 8);
  return \"MVC    %O0(8,%R0),%1\";
}"
   [(set_attr "length" "8")]
)


forces it to use XL8'00' instead of the default F'0' and that
seems to work.  Does that seem like a proper solution to
you?

Unfortunately there's still another problem I've noticed.
I'll put that in another message after I've investigated it.

BFN.  Paul.

Re: i370 port

[Paul Edwards]

And here is the same debug info as last time ...

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "rtl.h"

rtx
foo (rtx addr, int size, int n_refs)
{
  int offset = 0;

  switch (GET_CODE (addr))
    {
    case PRE_INC:
      offset = (n_refs + 1) * size;
      break;
    case PRE_DEC:
      offset = -(n_refs + 1) * size;
      break;
    case POST_INC:
      offset = n_refs * size;
      break;
    }

  if (offset)
    addr = gen_rtx_PLUS (GET_MODE (addr), XEXP (addr, 0),
                         GEN_INT (offset));
  else
    addr = XEXP (addr, 0);

  return addr;
}


         COPY  PDPTOP
         CSECT
* Program text area
         DS    0F
* X-func foo prologue
FOO      PDPPRLG CINDEX=0,FRAME=120,BASER=12,ENTRY=YES
         B     FEN0
         LTORG
FEN0     EQU   *
         DROP  12
         BALR  12,0
         USING *,12
PG0      EQU   *
         LR    11,1
         L     10,=A(PGT0)
* Function foo code
         MVC 112(8,13),=F'0'
         SLR   8,8
         SLR   9,9
         LR    6,8
         LR    7,9
         L     3,0(11)
         L     2,8(11)
         LH    4,0(3)
         N     4,=XL4'0000FFFF'
         ST    4,104(13)
         LA    5,110(0,0)
         CLR   4,5
         BE    L3
         BH    L6
         LA    15,109(0,0)
         CLR   4,15
         BE    L4
         B     L7
L6       EQU   *
         L     5,104(13)
         LA    4,112(0,0)
         CLR   5,4
         BE    L5
         B     L7
L3       EQU   *
         A     2,=F'1'
         L     15,4(11)
         ST    15,116(13)
         L     4,112(13)
         L     5,4+112(13)
         MR    4,2
         ST    4,112(13)
         ST    5,4+112(13)
         LR    2,5
         B     L2
L4       EQU   *
         X     2,=F'-1'
         L     9,4(11)
         MR    8,2
         LR    2,9
         B     L2
L5       EQU   *
         L     7,4(11)
         MR    6,2
         LR    2,7
L2       EQU   *
         LTR   2,2
         BE    L7
         MVC   88(4,13),=F'0'
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(ZZZ@947)
         BALR  14,15
         MVC   88(4,13),=F'88'
         SLR   5,5
         IC    5,2(3)
         ST    5,92(13)
         MVC   96(4,13),4(3)
         ST    15,100(13)
         LA    1,88(,13)
         L     15,=V(ZZZ@957)
         BALR  14,15
         LR    3,15
         B     L8
L7       EQU   *
         L     3,4(3)
L8       EQU   *
         LR    15,3
* Function foo epilogue
         PDPEPIL
* Function foo literal pool
         DS    0F
         LTORG
* Function foo page table
         DS    0F
PGT0     EQU   *
         DC    A(PG0)
         END



;; Function foo

;; 8 regs to allocate: 37 28 29 31 (2) 35 (2) 34 (2) 26 27
;; 26 conflicts: 26 27 28 29 31 34 35 37 11 15
;; 27 conflicts: 26 27 28 31 34 35 37 11
;; 28 conflicts: 26 27 28 31 34 35 37 11
;; 29 conflicts: 26 29 11
;; 31 conflicts: 26 27 28 31 34 35 37 11
;; 34 conflicts: 26 27 28 31 34 35 37 11
;; 35 conflicts: 26 27 28 31 34 35 37 11
;; 37 conflicts: 26 27 28 31 34 35 37 11

Spilling for insn 3.
Spilling for insn 4.
Spilling for insn 5.
Spilling for insn 45.
Spilling for insn 46.
Using reg 15 for reload 0
Spilling for insn 48.
Using reg 4 for reload 0
Spilling for insn 50.
Using reg 4 for reload 0
Spilling for insn 55.
Using reg 4 for reload 0
Spilling for insn 19.
Spilling for insn 29.
Spilling for insn 37.
Spilling for insn 63.
Spilling for insn 64.
Spilling for insn 67.
Spilling for insn 71.
Using reg 2 for reload 0
Spilling for insn 72.
Spilling for insn 73.
Spilling for insn 80.
Register 37 now on stack.

Spilling for insn 3.
Spilling for insn 4.
Spilling for insn 5.
Spilling for insn 45.
Using reg 15 for reload 0
Spilling for insn 46.
Using reg 15 for reload 1
Using reg 4 for reload 0
Spilling for insn 48.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 50.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 55.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 19.
Spilling for insn 29.
Spilling for insn 37.
Spilling for insn 63.
Spilling for insn 64.
Spilling for insn 67.
Spilling for insn 71.
Using reg 2 for reload 0
Spilling for insn 72.
Spilling for insn 73.
Spilling for insn 80.
Register 31 now on stack.

Spilling for insn 113.
Spilling for insn 3.
Spilling for insn 4.
Spilling for insn 5.
Spilling for insn 45.
Using reg 4 for reload 0
Spilling for insn 46.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 48.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 50.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 55.
Using reg 4 for reload 1
Using reg 5 for reload 0
Spilling for insn 19.
Using reg 4 for reload 0
Spilling for insn 20.
Using reg 4 for reload 0
Spilling for insn 21.
Spilling for insn 29.
Spilling for insn 37.
Spilling for insn 63.
Spilling for insn 64.
Spilling for insn 67.
Spilling for insn 71.
Using reg 2 for reload 0
Spilling for insn 72.
Spilling for insn 73.
Spilling for insn 80.

Reloads for insn # 113
Reload 0: reload_out (DI) = (reg:DI 31 [ size ])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (reg:DI 31 [ size ])

Reloads for insn # 3
Reload 0: reload_in (SI) = (mem/f:SI (reg/f:SI 11 11) [2 addr+0 S4 A32])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem/f:SI (reg/f:SI 11 11) [2 addr+0 S4 A32])

Reloads for insn # 5
Reload 0: reload_in (SI) = (mem/f:SI (plus:SI (reg/f:SI 11 11)
                                                        (const_int 8 [0x8])) 
[3 n_refs+0 S4 A32])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem/f:SI (plus:SI (reg/f:SI 11 11)
                                                        (const_int 8 [0x8])) 
[3 n_refs+0 S4 A32])

Reloads for insn # 45
Reload 0: reload_in (HI) = (mem/s:HI (reg/v/f:SI 3 3 [orig:26 addr ] [26]) 
[4 S2 A32])
         reload_out (SI) = (reg:SI 37)
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (mem/s:HI (reg/v/f:SI 3 3 [orig:26 addr ] [26]) [4 
S2 A32])
         reload_out_reg: (reg:SI 37)
         reload_reg_rtx: (reg:SI 4 4)

Reloads for insn # 46
Reload 0: reload_in (SI) = (reg:SI 37)
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 0)
         reload_in_reg: (reg:SI 37)
         reload_reg_rtx: (reg:SI 4 4)
Reload 1: reload_in (SI) = (const_int 110 [0x6e])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 110 [0x6e])
         reload_reg_rtx: (reg:SI 5 5)

Reloads for insn # 48
Reload 0: reload_in (SI) = (reg:SI 37)
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 0)
         reload_in_reg: (reg:SI 37)
         reload_reg_rtx: (reg:SI 4 4)
Reload 1: reload_in (SI) = (const_int 110 [0x6e])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 110 [0x6e])
         reload_reg_rtx: (reg:SI 5 5)

Reloads for insn # 50
Reload 0: reload_in (SI) = (reg:SI 37)
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 0)
         reload_in_reg: (reg:SI 37)
         reload_reg_rtx: (reg:SI 4 4)
Reload 1: reload_in (SI) = (const_int 109 [0x6d])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 109 [0x6d])
         reload_reg_rtx: (reg:SI 15 15)

Reloads for insn # 55
Reload 0: reload_in (SI) = (reg:SI 37)
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 0)
         reload_in_reg: (reg:SI 37)
         reload_reg_rtx: (reg:SI 5 5)
Reload 1: reload_in (SI) = (const_int 112 [0x70])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 112 [0x70])
         reload_reg_rtx: (reg:SI 4 4)

Reloads for insn # 19
Reload 0: reload_out (SI) = (subreg:SI (reg:DI 31 [ size ]) 4)
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
         reload_out_reg: (subreg:SI (reg:DI 31 [ size ]) 4)
         reload_reg_rtx: (reg:SI 15 15)
Reload 1: reload_in (SI) = (reg/v:SI 27 [ size ])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (reg/v:SI 27 [ size ])

Reloads for insn # 20
Reload 0: reload_in (DI) = (reg:DI 31 [ size ])
         reload_out (DI) = (reg:DI 31 [ size ])
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (reg:DI 31 [ size ])
         reload_out_reg: (reg:DI 31 [ size ])
         reload_reg_rtx: (reg:DI 4 4)

Reloads for insn # 21
Reload 0: reload_in (SI) = (subreg:SI (reg:DI 31 [ size ]) 4)
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (subreg:SI (reg:DI 31 [ size ]) 4)
         reload_reg_rtx: (reg:SI 5 5)

Reloads for insn # 29
Reload 0: reload_in (SI) = (reg/v:SI 27 [ size ])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (reg/v:SI 27 [ size ])

Reloads for insn # 37
Reload 0: reload_in (SI) = (reg/v:SI 27 [ size ])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (reg/v:SI 27 [ size ])

Reloads for insn # 63
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 64
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 67
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 71
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         reload_reg_rtx: (reg:SI 5 5)

Reloads for insn # 72
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])

Reloads for insn # 73
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])

Reloads for insn # 80
Reload 0: reload_in (SI) = (mem/s:SI (plus:SI (reg/v/f:SI 3 3 [orig:26 
addr ] [26])
                                                        (const_int 4 [0x4])) 
[0 <variable>.rtx+0 S4 A32])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem/s:SI (plus:SI (reg/v/f:SI 3 3 [orig:26 addr ] 
[26])
                                                        (const_int 4 [0x4])) 
[0 <variable>.rtx+0 S4 A32])
;; Register dispositions:
26 in 3  28 in 2  29 in 2  34 in 8  35 in 6

;; Hard regs used:  2 3 4 5 6 7 8 9 11 13 15

(note 2 0 96 NOTE_INSN_DELETED)

;; Start of basic block 0, registers live: 11 [11] 13 [13]
(note 96 2 113 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(insn 113 96 114 0 (set (mem:DI (plus:SI (reg/f:SI 13 13)
                (const_int 112 [0x70])) [22 S8 A8])
        (const_int 0 [0x0])) 13 {*i370.md:786} (nil)
    (nil))

(insn 114 113 115 0 (set (reg:DI 8 8 [orig:34 size ] [34])
        (const_int 0 [0x0])) 13 {*i370.md:786} (nil)
    (nil))

(insn 115 114 3 0 (set (reg:DI 6 6 [orig:35 size ] [35])
        (const_int 0 [0x0])) 13 {*i370.md:786} (nil)
    (nil))

(insn 3 115 4 0 (set (reg/v/f:SI 3 3 [orig:26 addr ] [26])
        (mem/f:SI (reg/f:SI 11 11) [2 addr+0 S4 A32])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (mem/f:SI (reg/f:SI 11 11) [2 addr+0 S4 A32])
        (nil)))

(note 4 3 5 0 NOTE_INSN_DELETED)

(insn 5 4 6 0 (set (reg/v:SI 2 2 [orig:28 n_refs ] [28])
        (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 8 [0x8])) [3 n_refs+0 S4 A32])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 8 [0x8])) [3 n_refs+0 S4 A32])
        (nil)))

(note 6 5 44 0 NOTE_INSN_FUNCTION_BEG)

(note 44 6 117 0 NOTE_INSN_DELETED)

(insn 117 44 45 0 alias.c:15 (set (reg:HI 4 4)
        (mem/s:HI (reg/v/f:SI 3 3 [orig:26 addr ] [26]) [4 S2 A32])) 16 
{*i370.md:1004} (nil)
    (nil))

(insn 45 117 118 0 alias.c:15 (set (reg:SI 4 4)
        (zero_extend:SI (reg:HI 4 4))) 30 {zero_extendhisi2} (insn_list 3 
(nil))
    (nil))

(insn 118 45 119 0 alias.c:15 (set (mem:SI (plus:SI (reg/f:SI 13 13)
                (const_int 104 [0x68])) [21 S4 A8])
        (reg:SI 4 4)) 15 {movsi} (nil)
    (nil))

(insn 119 118 46 0 alias.c:15 (set (reg:SI 5 5)
        (const_int 110 [0x6e])) 15 {movsi} (nil)
    (nil))

(insn:QI 46 119 47 0 alias.c:15 (set (cc0)
        (compare (reg:SI 4 4)
            (reg:SI 5 5))) 5 {cmpsi} (insn_list 45 (nil))
    (nil))

(jump_insn 47 46 97 0 alias.c:15 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref 16)
            (pc))) 104 {beq} (nil)
    (expr_list:REG_BR_PROB (const_int 2900 [0xb54])
        (nil)))
;; End of basic block 0, registers live:
11 [11] 13 [13] 26 27 28 31 34 35 37

;; Start of basic block 1, registers live: 11 [11] 13 [13] 26 27 28 34 35 37
(note 97 47 48 1 [bb 1] NOTE_INSN_BASIC_BLOCK)

(insn:QI 48 97 49 1 alias.c:15 (set (cc0)
        (compare (reg:SI 4 4)
            (reg:SI 5 5))) 5 {cmpsi} (nil)
    (nil))

(jump_insn 49 48 98 1 alias.c:15 (set (pc)
        (if_then_else (gtu (cc0)
                (const_int 0 [0x0]))
            (label_ref 54)
            (pc))) 107 {bgtu} (nil)
    (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil)))
;; End of basic block 1, registers live:
11 [11] 13 [13] 26 27 28 34 35 37

;; Start of basic block 2, registers live: 11 [11] 13 [13] 26 27 28 34 37
(note 98 49 120 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 120 98 50 2 alias.c:15 (set (reg:SI 15 15)
        (const_int 109 [0x6d])) 15 {movsi} (nil)
    (nil))

(insn:QI 50 120 51 2 alias.c:15 (set (cc0)
        (compare (reg:SI 4 4)
            (reg:SI 15 15))) 5 {cmpsi} (nil)
    (nil))

(jump_insn 51 50 99 2 alias.c:15 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref 25)
            (pc))) 104 {beq} (nil)
    (expr_list:REG_BR_PROB (const_int 2900 [0xb54])
        (nil)))
;; End of basic block 2, registers live:
11 [11] 13 [13] 26 27 28 34

;; Start of basic block 3, registers live: 11 [11] 13 [13] 26
(note 99 51 52 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(jump_insn 52 99 53 3 alias.c:15 (set (pc)
        (label_ref 78)) 126 {jump} (nil)
    (nil))
;; End of basic block 3, registers live:
11 [11] 13 [13] 26

(barrier 53 52 54)

;; Start of basic block 4, registers live: 11 [11] 13 [13] 26 27 28 35 37
(code_label 54 53 100 4 6 "" [1 uses])

(note 100 54 121 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 121 100 122 4 alias.c:15 (set (reg:SI 5 5)
        (mem:SI (plus:SI (reg/f:SI 13 13)
                (const_int 104 [0x68])) [21 S4 A8])) 15 {movsi} (nil)
    (nil))

(insn 122 121 55 4 alias.c:15 (set (reg:SI 4 4)
        (const_int 112 [0x70])) 15 {movsi} (nil)
    (nil))

(insn:QI 55 122 56 4 alias.c:15 (set (cc0)
        (compare (reg:SI 5 5)
            (reg:SI 4 4))) 5 {cmpsi} (nil)
    (nil))

(jump_insn 56 55 101 4 alias.c:15 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref 35)
            (pc))) 104 {beq} (nil)
    (expr_list:REG_BR_PROB (const_int 2900 [0xb54])
        (nil)))
;; End of basic block 4, registers live:
11 [11] 13 [13] 26 27 28 35

;; Start of basic block 5, registers live: 11 [11] 13 [13] 26
(note 101 56 57 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(jump_insn 57 101 58 5 alias.c:15 (set (pc)
        (label_ref 78)) 126 {jump} (nil)
    (nil))
;; End of basic block 5, registers live:
11 [11] 13 [13] 26

(barrier 58 57 16)

;; Start of basic block 6, registers live: 11 [11] 13 [13] 26 27 28 31
(code_label 16 58 102 6 3 "" [1 uses])

(note 102 16 17 6 [bb 6] NOTE_INSN_BASIC_BLOCK)

(note 17 102 18 6 ("alias.c") 15)

(insn 18 17 19 6 alias.c:15 (set (reg/v:SI 2 2 [orig:28 n_refs ] [28])
        (plus:SI (reg/v:SI 2 2 [orig:28 n_refs ] [28])
            (const_int 1 [0x1]))) 41 {addsi3} (nil)
    (nil))

(insn 19 18 123 6 alias.c:15 (set (reg:SI 15 15)
        (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 4 [0x4])) [3 size+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 123 19 124 6 alias.c:15 (set (mem:SI (plus:SI (reg/f:SI 13 13)
                (const_int 116 [0x74])) [22 S4 A8])
        (reg:SI 15 15)) 15 {movsi} (nil)
    (nil))

(insn 124 123 20 6 alias.c:15 (set (reg:DI 4 4)
        (mem:DI (plus:SI (reg/f:SI 13 13)
                (const_int 112 [0x70])) [22 S8 A8])) 13 {*i370.md:786} (nil)
    (nil))

(insn 20 124 125 6 alias.c:15 (set (reg:DI 4 4)
        (mult:DI (reg:DI 4 4)
            (reg/v:SI 2 2 [orig:28 n_refs ] [28]))) 53 {*i370.md:2604} 
(insn_list 18 (insn_list 19 (nil)))
    (nil))

(insn 125 20 21 6 alias.c:15 (set (mem:DI (plus:SI (reg/f:SI 13 13)
                (const_int 112 [0x70])) [22 S8 A8])
        (reg:DI 4 4)) 13 {*i370.md:786} (nil)
    (nil))

(insn 21 125 22 6 alias.c:15 (set (reg/v:SI 2 2 [orig:29 offset ] [29])
        (reg:SI 5 5)) 15 {movsi} (insn_list 20 (nil))
    (expr_list:REG_EQUAL (mult:SI (reg:SI 30)
            (mem/f:SI (plus:SI (reg/f:SI 11 11)
                    (const_int 4 [0x4])) [3 size+0 S4 A32]))
        (nil)))

(note 22 21 23 6 ("alias.c") 16)

(jump_insn 23 22 24 6 alias.c:16 (set (pc)
        (label_ref 43)) 126 {jump} (nil)
    (nil))
;; End of basic block 6, registers live:
11 [11] 13 [13] 26 29

(barrier 24 23 25)

;; Start of basic block 7, registers live: 11 [11] 13 [13] 26 27 28 34
(code_label 25 24 103 7 4 "" [1 uses])

(note 103 25 26 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(note 26 103 27 7 ("alias.c") 18)

(note 27 26 28 7 NOTE_INSN_DELETED)

(insn 28 27 29 7 alias.c:18 (set (reg/v:SI 2 2 [orig:28 n_refs ] [28])
        (not:SI (reg/v:SI 2 2 [orig:28 n_refs ] [28]))) 86 {*i370.md:3685} 
(nil)
    (nil))

(insn 29 28 30 7 alias.c:18 (set (reg:SI 9 9 [orig:34 size+4 ] [34])
        (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 4 [0x4])) [3 size+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 30 29 31 7 alias.c:18 (set (reg:DI 8 8 [orig:34 size ] [34])
        (mult:DI (reg:DI 8 8 [orig:34 size ] [34])
            (reg/v:SI 2 2 [orig:28 n_refs ] [28]))) 53 {*i370.md:2604} 
(insn_list 28 (insn_list 29 (nil)))
    (nil))

(insn 31 30 32 7 alias.c:18 (set (reg/v:SI 2 2 [orig:29 offset ] [29])
        (reg:SI 9 9 [orig:34 size+4 ] [34])) 15 {movsi} (insn_list 30 (nil))
    (expr_list:REG_EQUAL (mult:SI (reg:SI 33)
            (mem/f:SI (plus:SI (reg/f:SI 11 11)
                    (const_int 4 [0x4])) [3 size+0 S4 A32]))
        (nil)))

(note 32 31 33 7 ("alias.c") 19)

(jump_insn 33 32 34 7 alias.c:19 (set (pc)
        (label_ref 43)) 126 {jump} (nil)
    (nil))
;; End of basic block 7, registers live:
11 [11] 13 [13] 26 29

(barrier 34 33 35)

;; Start of basic block 8, registers live: 11 [11] 13 [13] 26 27 28 35
(code_label 35 34 104 8 5 "" [1 uses])

(note 104 35 36 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

(note 36 104 37 8 ("alias.c") 21)

(insn 37 36 38 8 alias.c:21 (set (reg:SI 7 7 [orig:35 size+4 ] [35])
        (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 4 [0x4])) [3 size+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 38 37 39 8 alias.c:21 (set (reg:DI 6 6 [orig:35 size ] [35])
        (mult:DI (reg:DI 6 6 [orig:35 size ] [35])
            (reg/v:SI 2 2 [orig:28 n_refs ] [28]))) 53 {*i370.md:2604} 
(insn_list 37 (nil))
    (nil))

(insn 39 38 40 8 alias.c:21 (set (reg/v:SI 2 2 [orig:29 offset ] [29])
        (reg:SI 7 7 [orig:35 size+4 ] [35])) 15 {movsi} (insn_list 38 (nil))
    (expr_list:REG_EQUAL (mult:SI (reg/v:SI 2 2 [orig:28 n_refs ] [28])
            (mem/f:SI (plus:SI (reg/f:SI 11 11)
                    (const_int 4 [0x4])) [3 size+0 S4 A32]))
        (nil)))
;; End of basic block 8, registers live:
11 [11] 13 [13] 26 29

(note 40 39 43 ("alias.c") 22)

;; Start of basic block 9, registers live: 11 [11] 13 [13] 26 29
(code_label 43 40 105 9 2 "" [2 uses])

(note 105 43 60 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn:QI 60 105 61 9 alias.c:22 (set (cc0)
        (reg/v:SI 2 2 [orig:29 offset ] [29])) 1 {tstsi} (nil)
    (nil))

(jump_insn 61 60 106 9 alias.c:22 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref 78)
            (pc))) 104 {beq} (nil)
    (expr_list:REG_BR_PROB (const_int 7000 [0x1b58])
        (nil)))
;; End of basic block 9, registers live:
11 [11] 13 [13] 26 29

;; Start of basic block 10, registers live: 11 [11] 13 [13] 26 29
(note 106 61 63 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 63 106 64 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (const_int 0 [0x0])) 15 {movsi} (nil)
    (nil))

(insn 64 63 65 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg/v:SI 2 2 [orig:29 offset ] [29])) 15 {movsi} (nil)
    (nil))

(call_insn 65 64 66 10 alias.c:22 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("ZZZ_947") [flags 0x41] 
<function_decl c8c000 ZZZ_947>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(note 66 65 67 10 NOTE_INSN_DELETED)

(insn 67 66 68 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (const_int 88 [0x58])) 15 {movsi} (nil)
    (nil))

(note 68 67 69 10 NOTE_INSN_DELETED)

(note 69 68 70 10 NOTE_INSN_DELETED)

(note 70 69 71 10 NOTE_INSN_DELETED)

(insn 71 70 126 10 alias.c:22 (set (reg:SI 5 5)
        (zero_extend:SI (mem/s:QI (plus:SI (reg/v/f:SI 3 3 [orig:26 addr ] 
[26])
                    (const_int 2 [0x2])) [4 S1 A16]))) 31 {zero_extendqisi2} 
(nil)
    (nil))

(insn 126 71 72 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg:SI 5 5)) 15 {movsi} (nil)
    (nil))

(insn 72 126 73 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 96 [0x60])) [0 S4 A32])
        (mem/s:SI (plus:SI (reg/v/f:SI 3 3 [orig:26 addr ] [26])
                (const_int 4 [0x4])) [0 <variable>.rtx+0 S4 A32])) 15 
{movsi} (nil)
    (nil))

(insn 73 72 74 10 alias.c:22 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 100 [0x64])) [0 S4 A32])
        (reg:SI 15 15)) 15 {movsi} (insn_list 65 (nil))
    (nil))

(call_insn 74 73 75 10 alias.c:22 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("ZZZ_957") [flags 0x41] 
<function_decl c63af8 ZZZ_957>) [0 S1 A8])
            (const_int 16 [0x10]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 75 74 76 10 alias.c:22 (set (reg/v/f:SI 3 3 [orig:26 addr ] [26])
        (reg:SI 15 15)) 15 {movsi} (insn_list 74 (nil))
    (nil))

(jump_insn 76 75 77 10 alias.c:22 (set (pc)
        (label_ref 81)) 126 {jump} (nil)
    (nil))
;; End of basic block 10, registers live:
11 [11] 13 [13] 26

(barrier 77 76 78)

;; Start of basic block 11, registers live: 11 [11] 13 [13] 26
(code_label 78 77 107 11 7 "" [3 uses])

(note 107 78 80 11 [bb 11] NOTE_INSN_BASIC_BLOCK)

(insn 80 107 81 11 alias.c:22 (set (reg/v/f:SI 3 3 [orig:26 addr ] [26])
        (mem/s:SI (plus:SI (reg/v/f:SI 3 3 [orig:26 addr ] [26])
                (const_int 4 [0x4])) [0 <variable>.rtx+0 S4 A32])) 15 
{movsi} (nil)
    (nil))
;; End of basic block 11, registers live:
11 [11] 13 [13] 26

;; Start of basic block 12, registers live: 11 [11] 13 [13] 26
(code_label 81 80 108 12 8 "" [1 uses])

(note 108 81 89 12 [bb 12] NOTE_INSN_BASIC_BLOCK)

(note 89 108 92 12 NOTE_INSN_FUNCTION_END)

(insn 92 89 95 12 alias.c:22 (set (reg/i:SI 15 15 [ <result> ])
        (reg/v/f:SI 3 3 [orig:26 addr ] [26])) 15 {movsi} (nil)
    (nil))

(insn 95 92 116 12 alias.c:22 (use (reg/i:SI 15 15 [ <result> ])) -1 
(insn_list 92 (nil))
    (nil))
;; End of basic block 12, registers live:
11 [11] 13 [13] 15 [15]

(note 116 95 0 NOTE_INSN_DELETED)

Re: i370 port

[Paul Edwards]

> (like the 8 byte move from F'0').  I'll do my own investigation
> of that and report that later.

Ok, the bad MVC:

MVC 112(8,13),=F'0'

is being generated by the movdi instruction:

;
; movdi instruction pattern(s).
;

(define_insn ""
  [(set (match_operand:DI 0 "nonimmediate_operand" "=d,m,S")
        (match_operand:DI 1 "general_operand" "g,d,SF"))]
;;  [(set (match_operand:DI 0 "r_or_s_operand" "=dS,m")
;;        (match_operand:DI 1 "r_or_s_operand" "diS*fF,d*fF"))]
  "TARGET_CHAR_INSTRUCTIONS"
  "*
{
...
  return \"MVC^I%O0(8,%R0),%1\";
}"

which looks correct to me.  The problem seems to be an =F'0' being
treated as a DI operand.

That extra memory constraint thing must be allowing this rogue
value through that was normally not picked up.

Any ideas?

Thanks.  Paul.

Re: i370 port

[Paul Edwards]

Well done!  That generated sensible code:

L     15,=V(PRINTF)
BALR  14,15
L     3,=F'32880'
AR    3,13
MVC   0(10,3),0(2)


I still have the other knock-on effects from when I did this though:

C:\devel\gcc\gcc\config\i370>cvs diff i370.h
Index: i370.h
===================================================================
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.17
diff -r1.17 i370.h
599a600,602
> #define EXTRA_MEMORY_CONSTRAINT(C, STR) \
>   ((C) == 'S')
>

(like the 8 byte move from F'0').  I'll do my own investigation
of that and report that later.

BFN.  Paul.



-----Original Message----- 
From: Ulrich Weigand
Sent: Thursday, August 18, 2011 11:14 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:

> Hi Ulrich.  I put in the following debug:
>
>       op0 = find_replacement (&XEXP (in, 0));
>       op1 = find_replacement (&XEXP (in, 1));
>
>       /* Since constraint checking is strict, commutativity won't be
> checked, so we need to do that here to avoid spurious failure
> if the add instruction is two-address and the second operand
> of the add is the same as the reload reg, which is frequently
> the case.  If the insn would be A = B + A, rearrange it so
> it will be A = A + B as constrain_operands expects.  */
>
>       fprintf(stderr, "REGNO(out) is %d\n", REGNO(out));
>       fprintf(stderr, " REG in 1 is %d\n", REGNO(XEXP(in,1)));
>       if (GET_CODE (XEXP (in, 1)) == REG
>   && REGNO (out) == REGNO (XEXP (in, 1)))
>   tem = op0, op0 = op1, op1 = tem;
>
> And it produced this output (for exactly the same code I showed
> you previously):
>
> C:\devel\pdos\s370>\devel\gcc\gcc\gccmvs -da -DUSE_MEMMGR -Os -DS390 -S -I
> . -I ../pdpclib pdos.c
> REGNO(out) is 3
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 112
> REGNO(out) is 3
> REG in 1 is 32880
> REGNO(out) is 4
> REG in 1 is 112
> REGNO(out) is 2
> REG in 1 is 112
>
> which looks to me like it is not seeing a register, only a constant,
> so cannot perform a swap.

Oops, there's clearly a bug here.  "in" at this point is the original
expression that has not yet been reloaded, so its second operand will
indeed be a constant, not a register.  However, reload has already
decided that this constant will end up being replaced by a register,
and that is what the "find_replacement" call is checking.

So at this point in the program, XEXP (in, 1) will be the constant,
but op1 will be the register it is going to be replaced with.

Unfortunately the test whether to swap looks at XEXP (in, 1) -- it
really needs to look at op1 instead.

Can you try changing the lines

      if (GET_CODE (XEXP (in, 1)) == REG
          && REGNO (out) == REGNO (XEXP (in, 1)))

to

      if (GET_CODE (op1) == REG
          && REGNO (out) == REGNO (op1))

instead?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com 

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> Hi Ulrich.  I put in the following debug:
> 
>       op0 = find_replacement (&XEXP (in, 0));
>       op1 = find_replacement (&XEXP (in, 1));
> 
>       /* Since constraint checking is strict, commutativity won't be
> checked, so we need to do that here to avoid spurious failure
> if the add instruction is two-address and the second operand
> of the add is the same as the reload reg, which is frequently
> the case.  If the insn would be A = B + A, rearrange it so
> it will be A = A + B as constrain_operands expects.  */
> 
>       fprintf(stderr, "REGNO(out) is %d\n", REGNO(out));
>       fprintf(stderr, " REG in 1 is %d\n", REGNO(XEXP(in,1)));
>       if (GET_CODE (XEXP (in, 1)) == REG
>   && REGNO (out) == REGNO (XEXP (in, 1)))
>   tem = op0, op0 = op1, op1 = tem;
> 
> And it produced this output (for exactly the same code I showed
> you previously):
> 
> C:\devel\pdos\s370>\devel\gcc\gcc\gccmvs -da -DUSE_MEMMGR -Os -DS390 -S -I 
> . -I ../pdpclib pdos.c
> REGNO(out) is 3
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 32880
> REGNO(out) is 2
> REG in 1 is 112
> REGNO(out) is 3
> REG in 1 is 32880
> REGNO(out) is 4
> REG in 1 is 112
> REGNO(out) is 2
> REG in 1 is 112
> 
> which looks to me like it is not seeing a register, only a constant,
> so cannot perform a swap.

Oops, there's clearly a bug here.  "in" at this point is the original
expression that has not yet been reloaded, so its second operand will
indeed be a constant, not a register.  However, reload has already
decided that this constant will end up being replaced by a register,
and that is what the "find_replacement" call is checking.

So at this point in the program, XEXP (in, 1) will be the constant,
but op1 will be the register it is going to be replaced with.

Unfortunately the test whether to swap looks at XEXP (in, 1) -- it
really needs to look at op1 instead.

Can you try changing the lines

      if (GET_CODE (XEXP (in, 1)) == REG
          && REGNO (out) == REGNO (XEXP (in, 1)))

to

      if (GET_CODE (op1) == REG
          && REGNO (out) == REGNO (op1))

instead?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi Ulrich.  I put in the following debug:

      op0 = find_replacement (&XEXP (in, 0));
      op1 = find_replacement (&XEXP (in, 1));

      /* Since constraint checking is strict, commutativity won't be
checked, so we need to do that here to avoid spurious failure
if the add instruction is two-address and the second operand
of the add is the same as the reload reg, which is frequently
the case.  If the insn would be A = B + A, rearrange it so
it will be A = A + B as constrain_operands expects.  */

      fprintf(stderr, "REGNO(out) is %d\n", REGNO(out));
      fprintf(stderr, " REG in 1 is %d\n", REGNO(XEXP(in,1)));
      if (GET_CODE (XEXP (in, 1)) == REG
  && REGNO (out) == REGNO (XEXP (in, 1)))
  tem = op0, op0 = op1, op1 = tem;

And it produced this output (for exactly the same code I showed
you previously):

C:\devel\pdos\s370>\devel\gcc\gcc\gccmvs -da -DUSE_MEMMGR -Os -DS390 -S -I 
. -I ../pdpclib pdos.c
REGNO(out) is 3
REG in 1 is 32880
REGNO(out) is 2
REG in 1 is 32880
REGNO(out) is 2
REG in 1 is 32880
REGNO(out) is 2
REG in 1 is 112
REGNO(out) is 3
REG in 1 is 32880
REGNO(out) is 4
REG in 1 is 112
REGNO(out) is 2
REG in 1 is 112

which looks to me like it is not seeing a register, only a constant,
so cannot perform a swap.

Let me know if that is not the debugging required.

Thanks.  Paul.




-----Original Message----- 
From: Ulrich Weigand
Sent: Tuesday, August 16, 2011 11:25 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:
> >> Unfortunately it's not quite right, seemingly not loading R9 properly:
> >>
> >> LR    9,13
> >> AR    9,13
> >> MVC   0(10,9),0(2)
>
> > That's weird.  What does the reload dump (.greg) say?
>
> I have trimmed the code down to a reasonably small size so that I
> could provide the .greg file (below) from the "-da" option.  I don't
> know how to read it so I don't know if I've provided everything
> required.
>
> Here is the current problematic generated code:
>
> * Function pdosLoadExe code
>          L     2,4(11)
>          MVC   88(4,13),=A(LC0)
>          ST    2,92(13)
>          LA    1,88(,13)
>          L     15,=V(PRINTF)
>          BALR  14,15
>          LR    3,13           <========= probably wrong
>          AR    3,13           <========= else this is wrong
>          MVC   0(10,3),0(2)

Reload decides on the following actions:

> Reloads for insn # 38
> Reload 0: reload_in (SI) = (const_int 32880 [0x8070])
>          ADDR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
>          reload_in_reg: (const_int 32880 [0x8070])
>          reload_reg_rtx: (reg:SI 3 3)
> Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
>                                                     (const_int 32880
> [0x8070]))
>          ADDR_REGS, RELOAD_FOR_INPUT (opnum = 0)
>          reload_in_reg: (plus:SI (reg/f:SI 13 13)
>                                                     (const_int 32880
> [0x8070]))
>          reload_reg_rtx: (reg:SI 3 3)

That is, first: load the constant 32880 into register 3,
and second: using that reloaded constant, compute the sum
of register 13 plus 32880 and load the result also into
register 3.  Then, use that register for addressing.

This leads to the following generated code:

> (insn 271 37 273 0 (set (reg:SI 3 3)
>         (const_int 32880 [0x8070])) 15 {movsi} (nil)
>     (nil))

Load constant into register 3.

> (insn 273 271 274 0 (set (reg:SI 3 3)
>         (reg/f:SI 13 13)) 15 {movsi} (nil)
>     (nil))
>
> (insn 274 273 38 0 (set (reg:SI 3 3)
>         (plus:SI (reg:SI 3 3)
>             (reg:SI 3 3))) 41 {addsi3} (nil)
>     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
>             (reg:SI 3 3))
>         (nil)))

Compute the sum.  Note that this code is wrong.

> (insn 38 274 41 0 (parallel [
>             (set (mem/s:BLK (reg:SI 3 3) [6 srchprog+0 S10 A64])
>                 (mem:BLK (reg/v/f:SI 2 2 [orig:27 prog ] [27]) [0 S10 
> A8]))
>             (use (const_int 10 [0xa]))
>         ]) 25 {*i370.md:1623} (insn_list 37 (nil))
>     (nil))

Use register 3 for adressing.

The wrong code comes in when generating the sum (insns 273/274).
I would have expected this to be a simple addsi3 instruction, along the
lines of

(set (reg:SI 3 3) (plus:SI (reg:SI 3 3) (reg:SI 13 13)))

Note that the incoming pattern:

(set (reg:SI 3 3) (plus:SI (reg:SI 13 13) (reg:SI 3 3)))

cannot be immediately resolved, since addsi3 requires the first
operand of the plus to match the result.

However, this could have been fixed by just swapping the operands.
Instead, the code attempts to create the match by reloading the
first operand (reg 13) into the output (reg 3) -- this is bogus,
since it thereby clobbers the *second* input operand, which happens
to match the output.

The code that generates these insns is in reload1.c:gen_reload

      /* We need to compute the sum of a register or a MEM and another
         register, constant, or MEM, and put it into the reload
         register.  The best possible way of doing this is if the machine
         has a three-operand ADD insn that accepts the required operands.

         The simplest approach is to try to generate such an insn and see if 
it
         is recognized and matches its constraints.  If so, it can be used.

         It might be better not to actually emit the insn unless it is 
valid,
         but we need to pass the insn as an operand to `recog' and
         `extract_insn' and it is simpler to emit and then delete the insn 
if
         not valid than to dummy things up.  */

      rtx op0, op1, tem, insn;
      int code;

      op0 = find_replacement (&XEXP (in, 0));
      op1 = find_replacement (&XEXP (in, 1));

      /* Since constraint checking is strict, commutativity won't be
         checked, so we need to do that here to avoid spurious failure
         if the add instruction is two-address and the second operand
         of the add is the same as the reload reg, which is frequently
         the case.  If the insn would be A = B + A, rearrange it so
         it will be A = A + B as constrain_operands expects.  */

      if (GET_CODE (XEXP (in, 1)) == REG
          && REGNO (out) == REGNO (XEXP (in, 1)))
        tem = op0, op0 = op1, op1 = tem;

      if (op0 != XEXP (in, 0) || op1 != XEXP (in, 1))
        in = gen_rtx_PLUS (GET_MODE (in), op0, op1);

      insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
      code = recog_memoized (insn);

Note how this actually performs the check whether to swap operands
for commutativity.

Can you debug this and find out why this doesn't work in your case?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com 

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:
> >> Unfortunately it's not quite right, seemingly not loading R9 properly:
> >>
> >> LR    9,13
> >> AR    9,13
> >> MVC   0(10,9),0(2)
> 
> > That's weird.  What does the reload dump (.greg) say?
> 
> I have trimmed the code down to a reasonably small size so that I
> could provide the .greg file (below) from the "-da" option.  I don't
> know how to read it so I don't know if I've provided everything
> required.
> 
> Here is the current problematic generated code:
> 
> * Function pdosLoadExe code
>          L     2,4(11)
>          MVC   88(4,13),=A(LC0)
>          ST    2,92(13)
>          LA    1,88(,13)
>          L     15,=V(PRINTF)
>          BALR  14,15
>          LR    3,13           <========= probably wrong
>          AR    3,13           <========= else this is wrong
>          MVC   0(10,3),0(2)

Reload decides on the following actions:

> Reloads for insn # 38
> Reload 0: reload_in (SI) = (const_int 32880 [0x8070])
>          ADDR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
>          reload_in_reg: (const_int 32880 [0x8070])
>          reload_reg_rtx: (reg:SI 3 3)
> Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
>                                                     (const_int 32880 
> [0x8070]))
>          ADDR_REGS, RELOAD_FOR_INPUT (opnum = 0)
>          reload_in_reg: (plus:SI (reg/f:SI 13 13)
>                                                     (const_int 32880 
> [0x8070]))
>          reload_reg_rtx: (reg:SI 3 3)

That is, first: load the constant 32880 into register 3,
and second: using that reloaded constant, compute the sum
of register 13 plus 32880 and load the result also into
register 3.  Then, use that register for addressing.

This leads to the following generated code:

> (insn 271 37 273 0 (set (reg:SI 3 3)
>         (const_int 32880 [0x8070])) 15 {movsi} (nil)
>     (nil))

Load constant into register 3.

> (insn 273 271 274 0 (set (reg:SI 3 3)
>         (reg/f:SI 13 13)) 15 {movsi} (nil)
>     (nil))
> 
> (insn 274 273 38 0 (set (reg:SI 3 3)
>         (plus:SI (reg:SI 3 3)
>             (reg:SI 3 3))) 41 {addsi3} (nil)
>     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
>             (reg:SI 3 3))
>         (nil)))

Compute the sum.  Note that this code is wrong.

> (insn 38 274 41 0 (parallel [
>             (set (mem/s:BLK (reg:SI 3 3) [6 srchprog+0 S10 A64])
>                 (mem:BLK (reg/v/f:SI 2 2 [orig:27 prog ] [27]) [0 S10 A8]))
>             (use (const_int 10 [0xa]))
>         ]) 25 {*i370.md:1623} (insn_list 37 (nil))
>     (nil))

Use register 3 for adressing.

The wrong code comes in when generating the sum (insns 273/274).
I would have expected this to be a simple addsi3 instruction, along the
lines of

(set (reg:SI 3 3) (plus:SI (reg:SI 3 3) (reg:SI 13 13)))

Note that the incoming pattern:

(set (reg:SI 3 3) (plus:SI (reg:SI 13 13) (reg:SI 3 3)))

cannot be immediately resolved, since addsi3 requires the first
operand of the plus to match the result.

However, this could have been fixed by just swapping the operands.
Instead, the code attempts to create the match by reloading the
first operand (reg 13) into the output (reg 3) -- this is bogus,
since it thereby clobbers the *second* input operand, which happens
to match the output.

The code that generates these insns is in reload1.c:gen_reload

      /* We need to compute the sum of a register or a MEM and another
         register, constant, or MEM, and put it into the reload
         register.  The best possible way of doing this is if the machine
         has a three-operand ADD insn that accepts the required operands.

         The simplest approach is to try to generate such an insn and see if it
         is recognized and matches its constraints.  If so, it can be used.

         It might be better not to actually emit the insn unless it is valid,
         but we need to pass the insn as an operand to `recog' and
         `extract_insn' and it is simpler to emit and then delete the insn if
         not valid than to dummy things up.  */

      rtx op0, op1, tem, insn;
      int code;

      op0 = find_replacement (&XEXP (in, 0));
      op1 = find_replacement (&XEXP (in, 1));

      /* Since constraint checking is strict, commutativity won't be
         checked, so we need to do that here to avoid spurious failure
         if the add instruction is two-address and the second operand
         of the add is the same as the reload reg, which is frequently
         the case.  If the insn would be A = B + A, rearrange it so
         it will be A = A + B as constrain_operands expects.  */

      if (GET_CODE (XEXP (in, 1)) == REG
          && REGNO (out) == REGNO (XEXP (in, 1)))
        tem = op0, op0 = op1, op1 = tem;

      if (op0 != XEXP (in, 0) || op1 != XEXP (in, 1))
        in = gen_rtx_PLUS (GET_MODE (in), op0, op1);

      insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
      code = recog_memoized (insn);

Note how this actually performs the check whether to swap operands
for commutativity.

Can you debug this and find out why this doesn't work in your case?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> Unfortunately it's not quite right, seemingly not loading R9 properly:
>>
>> LR    9,13
>> AR    9,13
>> MVC   0(10,9),0(2)

> That's weird.  What does the reload dump (.greg) say?

I have trimmed the code down to a reasonably small size so that I
could provide the .greg file (below) from the "-da" option.  I don't
know how to read it so I don't know if I've provided everything
required.

Here is the current problematic generated code:

* Function pdosLoadExe code
         L     2,4(11)
         MVC   88(4,13),=A(LC0)
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         LR    3,13           <========= probably wrong
         AR    3,13           <========= else this is wrong
         MVC   0(10,3),0(2)

Thanks.  Paul.



#include <stdio.h>
#include <string.h>

#define MAXBLKSZ 32767

typedef struct { int ipldev; } PDOS;

typedef struct {
    char ds1dsnam[44]; /* dataset name */
    char ds1fmtid; /* must be set to '1' */
    char startcchh[4];
} DSCB1;



int pdosLoadExe(PDOS *pdos, char *prog, char *parm)
{
    char *raw;
    char *initial;
    char *load;
    /* Standard C programs can start at a predictable offset */
    int entry;
    int cyl;
    int head;
    int rec;
    int i;
    int j;
    char tbuf[MAXBLKSZ];
    char srchprog[FILENAME_MAX+10]; /* give an extra space */
    int cnt = -1;
    int lastcnt = 0;
    int ret = 0;
    DSCB1 dscb1;
    int pe = 0;
    int exeLen;

    /* try to find the load module's location */

    printf("in pdosLoadExe with %.8s\n", prog);
    /* +++ replace this 8 with some constant */
    memcpy(srchprog, prog, 10);
    printf("srchprog now %.8s\n", srchprog);
    srchprog[8] = ' ';
    *strchr(srchprog, ' ') = '\0';
    strcat(srchprog, ".EXE "); /* extra space deliberate */
    printf("going to search for %s\n", srchprog);

    /* read VOL1 record */
    cnt = rdblock(pdos->ipldev, 0, 0, 3, tbuf, MAXBLKSZ);
    if (cnt >= 20)
    {
        cyl = head = rec = 0;
        /* +++ probably time to create some macros for this */
        memcpy((char *)&cyl + sizeof(int) - 2, tbuf + 15, 2);
        memcpy((char *)&head + sizeof(int) - 2, tbuf + 17, 2);
        memcpy((char *)&rec + sizeof(int) - 1, tbuf + 19, 1);

        while ((cnt =
               rdblock(pdos->ipldev, cyl, head, rec, &dscb1, sizeof dscb1))
               > 0)
        {
            if (cnt >= sizeof dscb1)
            {
                if (dscb1.ds1fmtid == '1')
                {
                    dscb1.ds1fmtid = ' '; /* for easy comparison */
                    if (memcmp(dscb1.ds1dsnam,
                               srchprog,
                               strlen(srchprog)) == 0)
                    {
                        cyl = head = 0;
                        rec = 1;
                        /* +++ more macros needed here */
                        memcpy((char *)&cyl + sizeof(int) - 2,
                               dscb1.startcchh, 2);
                        memcpy((char *)&head + sizeof(int) - 2,
                               dscb1.startcchh + 2, 2);
                        break;
                    }
                }
            }
            rec++;
        }
    }

    if (cnt <= 0)
    {
        printf("about to zap %s\n", srchprog);
        *strchr(srchprog, ' ') = '\0';
        printf("executable %s not found!\n", srchprog);
        return (-1);
    }

    return (ret);
}




         COPY  PDPTOP
         CSECT
* Program text area
LC0      EQU   *
         DC    C'in pdosLoadExe with %.8s'
         DC    X'15'
         DC    X'0'
LC1      EQU   *
         DC    C'srchprog now %.8s'
         DC    X'15'
         DC    X'0'
LC2      EQU   *
         DC    C'.EXE '
         DC    X'0'
LC3      EQU   *
         DC    C'going to search for %s'
         DC    X'15'
         DC    X'0'
LC4      EQU   *
         DC    C'about to zap %s'
         DC    X'15'
         DC    X'0'
LC5      EQU   *
         DC    C'executable %s not found!'
         DC    X'15'
         DC    X'0'
         DS    0F
* X-func pdosLoadExe prologue
PDOSLOAD PDPPRLG CINDEX=0,FRAME=33224,BASER=12,ENTRY=YES
         B     FEN0
         LTORG
FEN0     EQU   *
         DROP  12
         BALR  12,0
         USING *,12
PG0      EQU   *
         LR    11,1
         L     10,=A(PGT0)
* Function pdosLoadExe code
         L     2,4(11)
         MVC   88(4,13),=A(LC0)
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         LR    3,13
         AR    3,13
         MVC   0(10,3),0(2)
         MVC   88(4,13),=A(LC1)
         L     2,=F'32880'
         AR    2,13
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         L     2,=F'32768'
         LA    3,64(0,0)
         STC   3,120(2,13)
         L     2,=F'32880'
         AR    2,13
         ST    2,88(13)
         MVC   92(4,13),=F'64'
         LA    1,88(,13)
         L     15,=V(STRCHR)
         BALR  14,15
         MVI   0(15),0
         ST    2,88(13)
         MVC   92(4,13),=A(LC2)
         LA    1,88(,13)
         L     15,=V(STRCAT)
         BALR  14,15
         MVC   88(4,13),=A(LC3)
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         L     3,0(11)
         MVC   88(4,13),0(3)
         MVC   92(4,13),=F'0'
         MVC   96(4,13),=F'0'
         MVC   100(4,13),=F'3'
         LA    2,112(,13)
         ST    2,104(13)
         MVC   108(4,13),=F'32767'
         LA    1,88(,13)
         L     15,=V(RDBLOCK)
         BALR  14,15
         LR    6,15
         LA    3,19(0,0)
         CR    15,3
         BNH   L2
         L     2,=F'33216'
         AR    2,13
         MVC   0(4,2),=F'0'
         L     9,=F'33212'
         AR    9,13
         MVC   0(4,9),=F'0'
         L     8,=F'33208'
         AR    8,13
         MVC   0(4,8),=F'0'
         MVC   2(2,8),127(13)
         MVC   2(2,9),129(13)
         MVC   3(1,2),131(13)
         B     L3
L8       EQU   *
         LA    2,48(0,0)
         CLR   6,2
         BNH   L5
         L     3,=F'33040'
         IC    2,156(3,13)
         CLM   2,1,=XL1'F1'
         BNE   L5
         LA    2,64(0,0)
         STC   2,156(3,13)
         L     3,=F'32880'
         AR    3,13
         ST    3,88(13)
         LA    1,88(,13)
         L     15,=V(STRLEN)
         BALR  14,15
         LA    4,112(,13)
         A     4,=F'33040'
         LR    5,15
         LA    2,112(,13)
         A     2,=F'32768'
         LR    3,15
         LA    15,1(0,0)
         CLCL  4,2
         BH    *+12
         BL    *+6
         SLR   15,15
         LNR   15,15
         LTR   15,15
         BE    L10
L5       EQU   *
         L     2,0(7)
         A     2,=F'1'
         ST    2,0(7)
L3       EQU   *
         L     3,0(11)
         MVC   88(4,13),0(3)
         MVC   92(4,13),0(8)
         MVC   96(4,13),0(9)
         L     7,=F'33216'
         AR    7,13
         MVC   100(4,13),0(7)
         LR    2,13
         A     2,=F'33152'
         ST    2,104(13)
         MVC   108(4,13),=F'49'
         LA    1,88(,13)
         L     15,=V(RDBLOCK)
         BALR  14,15
         LR    6,15
         LTR   15,15
         BH    L8
L2       EQU   *
         SLR   15,15
         LTR   6,6
         BH    L1
         MVC   88(4,13),=A(LC4)
         L     2,=F'32880'
         AR    2,13
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         ST    2,88(13)
         MVC   92(4,13),=F'64'
         LA    1,88(,13)
         L     15,=V(STRCHR)
         BALR  14,15
         MVI   0(15),0
         MVC   88(4,13),=A(LC5)
         ST    2,92(13)
         LA    1,88(,13)
         L     15,=V(PRINTF)
         BALR  14,15
         L     15,=F'-1'
         B     L1
L10      EQU   *
         ST    15,0(9)
         ST    15,0(8)
         MVC   0(4,7),=F'1'
         L     2,=F'33085'
         LH    2,112(2,13)
         STH   2,2(8)
         L     2,=F'33087'
         LH    2,112(2,13)
         STH   2,2(9)
         B     L2
L1       EQU   *
* Function pdosLoadExe epilogue
         PDPEPIL
* Function pdosLoadExe literal pool
         DS    0F
         LTORG
* Function pdosLoadExe page table
         DS    0F
PGT0     EQU   *
         DC    A(PG0)
         END




;; Function pdosLoadExe

;; 12 regs to allocate: 74 (2) 73 (2) 66 41 63 25 106 100 105 47 90 26
;; 25 conflicts: 25 41 11
;; 25 preferences: 15
;; 26 conflicts: 26 27 41 46 47 63 64 66 70 73 74 90 100 105 106 111 2 11 15
;; 27 conflicts: 26 27 47 90 2 11 15
;; 41 conflicts: 25 26 41 47 63 64 66 70 73 74 79 82 90 100 105 106 2 11 15
;; 46 conflicts: 26 46 47 90 2 11
;; 47 conflicts: 26 27 41 46 47 63 64 66 70 73 74 90 100 105 106 111 2 11 15
;; 63 conflicts: 26 41 47 63 64 90 100 105 106 2 11
;; 64 conflicts: 26 41 47 63 64 90 100 105 106 2 11
;; 66 conflicts: 26 41 47 66 73 74 90 100 105 106 11
;; 70 conflicts: 26 41 47 70 73 74 90 100 105 106 11 15
;; 73 conflicts: 26 41 47 66 70 73 74 90 100 105 106 11 15
;; 74 conflicts: 26 41 47 66 70 73 74 90 100 105 106 11 15
;; 79 conflicts: 41 79 100 105 2 11
;; 82 conflicts: 41 82 105 2 11
;; 84 conflicts: 84 2 11 15
;; 90 conflicts: 26 27 41 46 47 63 64 66 70 73 74 90 100 105 106 111 2 11 15
;; 100 conflicts: 26 41 47 63 64 66 70 73 74 79 90 100 105 106 111 2 11 15
;; 105 conflicts: 26 41 47 63 64 66 70 73 74 79 82 90 100 105 106 111 2 11 
15
;; 106 conflicts: 26 41 47 63 64 66 70 73 74 90 100 105 106 2 11 15
;; 111 conflicts: 26 47 90 100 105 111 2 11

Spilling for insn 3.
Spilling for insn 4.
Spilling for insn 32.
Spilling for insn 33.
Spilling for insn 38.
Using reg 3 for reload 0
Using reg 3 for reload 1
Spilling for insn 41.
Spilling for insn 43.
Using reg 2 for reload 1
Spilling for insn 47.
Using reg 3 for reload 1
Spilling for insn 50.
Using reg 2 for reload 1
Spilling for insn 51.
Spilling for insn 54.
Spilling for insn 57.
Using reg 2 for reload 1
Spilling for insn 58.
Spilling for insn 61.
Spilling for insn 63.
Using reg 2 for reload 1
Spilling for insn 66.
Using reg 2 for reload 0
Spilling for insn 67.
Spilling for insn 68.
Spilling for insn 69.
Spilling for insn 70.
Using reg 2 for reload 1
Spilling for insn 71.
Spilling for insn 75.
Using reg 2 for reload 0
Spilling for insn 80.
Spilling for insn 81.
Spilling for insn 82.
Spilling for insn 86.
Spilling for insn 90.
Spilling for insn 94.
Spilling for insn 114.
Using reg 2 for reload 0
Spilling for insn 120.
Spilling for insn 127.
Using reg 2 for reload 1
Spilling for insn 132.
Using reg 2 for reload 1
Spilling for insn 139.
Spilling for insn 143.
Spilling for insn 173.
Using reg 2 for reload 0
Spilling for insn 98.
Using reg 2 for reload 0
Spilling for insn 99.
Spilling for insn 100.
Spilling for insn 101.
Spilling for insn 103.
Using reg 2 for reload 0
Spilling for insn 104.
Spilling for insn 189.
Spilling for insn 191.
Spilling for insn 195.
Spilling for insn 196.
Spilling for insn 199.
Spilling for insn 201.
Spilling for insn 203.
Spilling for insn 151.
Spilling for insn 152.
Spilling for insn 154.
Spilling for insn 159.
Spilling for insn 164.

Reloads for insn # 4
Reload 0: reload_in (SI) = (mem/f:SI (plus:SI (reg/f:SI 11 11)
                                                        (const_int 4 [0x4])) 
[3 prog+0 S4 A32])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem/f:SI (plus:SI (reg/f:SI 11 11)
                                                        (const_int 4 [0x4])) 
[3 prog+0 S4 A32])

Reloads for insn # 32
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 33
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 38
Reload 0: reload_in (SI) = (const_int 32880 [0x8070])
         ADDR_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
         reload_in_reg: (const_int 32880 [0x8070])
         reload_reg_rtx: (reg:SI 3 3)
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 0)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 3 3)

Reloads for insn # 41
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 43
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 47
Reload 0: reload_out (QI) = (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[46]))
                                                        (const_int 120 
[0x78])) [0 srchprog+8 S1 A64])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[46]))
                                                        (const_int 120 
[0x78])) [0 srchprog+8 S1 A64])
Reload 1: reload_in (QI) = (const_int 64 [0x40])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 64 [0x40])
         reload_reg_rtx: (reg:QI 3 3)

Reloads for insn # 50
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 51
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 54
Reload 0: reload_out (QI) = (mem:QI (reg:SI 15 15) [0 S1 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem:QI (reg:SI 15 15) [0 S1 A8])

Reloads for insn # 57
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 58
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 61
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 63
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 66
Reload 0: reload_in (SI) = (reg/v/f:SI 26 [ pdos ])
         ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1)
         reload_in_reg: (reg/v/f:SI 26 [ pdos ])
         reload_reg_rtx: (reg:SI 3 3)
Reload 1: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 67
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 68
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])

Reloads for insn # 69
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])

Reloads for insn # 70
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 104 
[0x68])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 104 
[0x68])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 71
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 108 
[0x6c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 108 
[0x6c])) [0 S4 A32])

Reloads for insn # 75
Reload 0: reload_in (SI) = (const_int 19 [0x13])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 19 [0x13])
         reload_reg_rtx: (reg:SI 3 3)

Reloads for insn # 80
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 2 2 [111]) [4 S4 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 2 2 [111]) [4 S4 A8])

Reloads for insn # 81
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 9 9 [105]) [4 S4 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 9 9 [105]) [4 S4 A8])

Reloads for insn # 82
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 8 8 [100]) [4 S4 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 8 8 [100]) [4 S4 A8])

Reloads for insn # 86
Reload 0: reload_out (HI) = (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])

Reloads for insn # 90
Reload 0: reload_out (HI) = (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])

Reloads for insn # 94
Reload 0: reload_out (QI) = (mem:QI (plus:SI (reg/f:SI 2 2 [111])
                                                        (const_int 3 [0x3])) 
[0 S1 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem:QI (plus:SI (reg/f:SI 2 2 [111])
                                                        (const_int 3 [0x3])) 
[0 S1 A8])

Reloads for insn # 114
Reload 0: reload_in (SI) = (const_int 48 [0x30])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 48 [0x30])
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 120
Reload 0: reload_in (QI) = (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 3 3 
[63]))
                                                        (const_int 156 
[0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 3 3 
[63]))
                                                        (const_int 156 
[0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])

Reloads for insn # 127
Reload 0: reload_out (QI) = (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 3 3 
[63]))
                                                        (const_int 156 
[0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 3 3 
[63]))
                                                        (const_int 156 
[0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])
Reload 1: reload_in (QI) = (const_int 64 [0x40])
         ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (const_int 64 [0x40])
         reload_reg_rtx: (reg:QI 2 2)

Reloads for insn # 132
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         ALL_REGS, RELOAD_FOR_INPUT (opnum = 1)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 32880 
[0x8070]))
         reload_reg_rtx: (reg:SI 3 3)

Reloads for insn # 139
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         reload_out (SI) = (reg:SI 4 4)
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         reload_out_reg: (subreg:SI (reg:DI 4 4 [73]) 0)
         reload_reg_rtx: (reg:SI 4 4)

Reloads for insn # 143
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         reload_out (SI) = (reg:SI 2 2)
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (plus:SI (reg/f:SI 13 13)
                                                    (const_int 112 [0x70]))
         reload_out_reg: (subreg:SI (reg:DI 2 2 [74]) 0)
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 173
Reload 0: reload_in (SI) = (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
         reload_out (SI) = (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
         reload_out_reg: (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 98
Reload 0: reload_in (SI) = (reg/v/f:SI 26 [ pdos ])
         ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1)
         reload_in_reg: (reg/v/f:SI 26 [ pdos ])
         reload_reg_rtx: (reg:SI 3 3)
Reload 1: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 99
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 100
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 96 
[0x60])) [0 S4 A32])

Reloads for insn # 101
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 100 
[0x64])) [0 S4 A32])

Reloads for insn # 103
Reload 0: reload_in (SI) = (reg/f:SI 13 13)
         reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 104 
[0x68])) [0 S4 A32])
         DATA_REGS, RELOAD_OTHER (opnum = 0)
         reload_in_reg: (reg/f:SI 13 13)
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 104 
[0x68])) [0 S4 A32])
         reload_reg_rtx: (reg:SI 2 2)

Reloads for insn # 104
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 108 
[0x6c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 108 
[0x6c])) [0 S4 A32])

Reloads for insn # 189
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 191
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 195
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 196
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 199
Reload 0: reload_out (QI) = (mem:QI (reg:SI 15 15) [0 S1 A8])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem:QI (reg:SI 15 15) [0 S1 A8])

Reloads for insn # 201
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 88 
[0x58])) [0 S4 A32])

Reloads for insn # 203
Reload 0: reload_out (SI) = (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (plus:SI (reg/f:SI 13 13)
                                                        (const_int 92 
[0x5c])) [0 S4 A32])

Reloads for insn # 151
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 9 9 [105]) [4 head+0 S4 
A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 9 9 [105]) [4 head+0 S4 A32])

Reloads for insn # 152
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 8 8 [100]) [4 cyl+0 S4 A32])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 8 8 [100]) [4 cyl+0 S4 A32])

Reloads for insn # 154
Reload 0: reload_out (SI) = (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
         NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
         reload_out_reg: (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])

Reloads for insn # 159
Reload 0: reload_out (HI) = (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
         reload_out_reg: (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         reload_reg_rtx: (reg:HI 2 2)
Reload 1: reload_in (HI) = (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[79]))
                                                        (const_int 112 
[0x70])) [0 S2 A8])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[79]))
                                                        (const_int 112 
[0x70])) [0 S2 A8])

Reloads for insn # 164
Reload 0: reload_out (HI) = (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
         reload_out_reg: (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                                                        (const_int 2 [0x2])) 
[0 S2 A16])
         reload_reg_rtx: (reg:HI 2 2)
Reload 1: reload_in (HI) = (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[82]))
                                                        (const_int 112 
[0x70])) [0 S2 A8])
         DATA_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
         reload_in_reg: (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                                                            (reg:SI 2 2 
[82]))
                                                        (const_int 112 
[0x70])) [0 S2 A8])
;; Register dispositions:
25 in 15  27 in 2  41 in 6  46 in 2  63 in 3  64 in 2
66 in 15  70 in 15  73 in 4  74 in 2  79 in 2  82 in 2
84 in 2  100 in 8  105 in 9  106 in 7  111 in 2

;; Hard regs used:  2 3 4 5 6 7 8 9 11 13 15

(note 2 0 227 NOTE_INSN_DELETED)

;; Start of basic block 0, registers live: 11 [11] 13 [13]
(note 227 2 3 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 3 227 4 0 NOTE_INSN_DELETED)

(insn 4 3 6 0 (set (reg/v/f:SI 2 2 [orig:27 prog ] [27])
        (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 4 [0x4])) [3 prog+0 S4 A32])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (mem/f:SI (plus:SI (reg/f:SI 11 11)
                (const_int 4 [0x4])) [3 prog+0 S4 A32])
        (nil)))

(note 6 4 32 0 NOTE_INSN_FUNCTION_BEG)

(insn 32 6 33 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC0") [flags 0x2] <string_cst 7d494c>)) 15 
{movsi} (nil)
    (nil))

(insn 33 32 34 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg/v/f:SI 2 2 [orig:27 prog ] [27])) 15 {movsi} (insn_list 4 
(nil))
    (nil))

(call_insn 34 33 244 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("printf") [flags 0x41] 
<function_decl 7729b4 printf>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(note 244 34 37 0 NOTE_INSN_DELETED)

(note 37 244 271 0 NOTE_INSN_DELETED)

(insn 271 37 273 0 (set (reg:SI 3 3)
        (const_int 32880 [0x8070])) 15 {movsi} (nil)
    (nil))

(insn 273 271 274 0 (set (reg:SI 3 3)
        (reg/f:SI 13 13)) 15 {movsi} (nil)
    (nil))

(insn 274 273 38 0 (set (reg:SI 3 3)
        (plus:SI (reg:SI 3 3)
            (reg:SI 3 3))) 41 {addsi3} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (reg:SI 3 3))
        (nil)))

(insn 38 274 41 0 (parallel [
            (set (mem/s:BLK (reg:SI 3 3) [6 srchprog+0 S10 A64])
                (mem:BLK (reg/v/f:SI 2 2 [orig:27 prog ] [27]) [0 S10 A8]))
            (use (const_int 10 [0xa]))
        ]) 25 {*i370.md:1623} (insn_list 37 (nil))
    (nil))

(insn 41 38 275 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC1") [flags 0x2] <string_cst 7d49d8>)) 15 
{movsi} (nil)
    (nil))

(insn 275 41 43 0 (set (reg:SI 2 2)
        (plus:SI (reg/f:SI 13 13)
            (const_int 32880 [0x8070]))) 40 {*i370.md:2127} (nil)
    (nil))

(insn 43 275 44 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(call_insn 44 43 269 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("printf") [flags 0x41] 
<function_decl 7729b4 printf>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 269 44 276 0 (set (reg:SI 2 2 [46])
        (const_int 32768 [0x8000])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (const_int 32768 [0x8000])
        (nil)))

(insn 276 269 47 0 (set (reg:QI 3 3)
        (const_int 64 [0x40])) 18 {*i370.md:1098} (nil)
    (nil))

(insn 47 276 277 0 (set (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 2 2 [46]))
                (const_int 120 [0x78])) [0 srchprog+8 S1 A64])
        (reg:QI 3 3)) 19 {movqi} (insn_list 36 (nil))
    (nil))

(insn 277 47 50 0 (set (reg:SI 2 2)
        (plus:SI (reg/f:SI 13 13)
            (const_int 32880 [0x8070]))) 40 {*i370.md:2127} (nil)
    (nil))

(insn 50 277 51 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(insn 51 50 52 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (const_int 64 [0x40])) 15 {movsi} (nil)
    (nil))

(call_insn 52 51 53 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("strchr") [flags 0x41] 
<function_decl 7b3654 strchr>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(note 53 52 54 0 NOTE_INSN_DELETED)

(insn 54 53 57 0 (set (mem:QI (reg:SI 15 15) [0 S1 A8])
        (const_int 0 [0x0])) 18 {*i370.md:1098} (insn_list 52 (nil))
    (nil))

(insn 57 54 58 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(insn 58 57 59 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC2") [flags 0x2] <string_cst 7d4a8c>)) 15 
{movsi} (nil)
    (nil))

(call_insn 59 58 61 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("strcat") [flags 0x41] 
<function_decl 7b1654 strcat>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 61 59 63 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC3") [flags 0x2] <string_cst 7d4adc>)) 15 
{movsi} (nil)
    (nil))

(insn 63 61 64 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(call_insn 64 63 278 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("printf") [flags 0x41] 
<function_decl 7729b4 printf>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 278 64 66 0 (set (reg:SI 3 3)
        (mem/f:SI (reg/f:SI 11 11) [2 pdos+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 66 278 67 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (mem/s:SI (reg:SI 3 3) [4 <variable>.ipldev+0 S4 A32])) 15 {movsi} 
(insn_list 3 (nil))
    (nil))

(insn 67 66 68 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (const_int 0 [0x0])) 15 {movsi} (nil)
    (nil))

(insn 68 67 69 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 96 [0x60])) [0 S4 A32])
        (const_int 0 [0x0])) 15 {movsi} (nil)
    (nil))

(insn 69 68 279 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 100 [0x64])) [0 S4 A32])
        (const_int 3 [0x3])) 15 {movsi} (nil)
    (nil))

(insn 279 69 70 0 (set (reg:SI 2 2)
        (plus:SI (reg/f:SI 13 13)
            (const_int 112 [0x70]))) 39 {*i370.md:2110} (nil)
    (nil))

(insn 70 279 71 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 104 [0x68])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (insn_list 244 (nil))
    (nil))

(insn 71 70 72 0 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 108 [0x6c])) [0 S4 A32])
        (const_int 32767 [0x7fff])) 15 {movsi} (nil)
    (nil))

(call_insn 72 71 73 0 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("rdblock") [flags 0x41] 
<function_decl 7bb21c rdblock>) [0 S1 A8])
            (const_int 24 [0x18]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 73 72 280 0 (set (reg/v:SI 6 6 [orig:41 cnt ] [41])
        (reg:SI 15 15)) 15 {movsi} (insn_list 72 (nil))
    (nil))

(insn 280 73 75 0 (set (reg:SI 3 3)
        (const_int 19 [0x13])) 15 {movsi} (nil)
    (nil))

(insn:QI 75 280 76 0 (set (cc0)
        (compare (reg/v:SI 6 6 [orig:41 cnt ] [41])
            (reg:SI 3 3))) 5 {cmpsi} (insn_list 73 (nil))
    (nil))

(jump_insn 76 75 228 0 (set (pc)
        (if_then_else (le (cc0)
                (const_int 0 [0x0]))
            (label_ref 182)
            (pc))) 112 {ble} (nil)
    (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil)))
;; End of basic block 0, registers live:
11 [11] 13 [13] 26 41 47 90

;; Start of basic block 1, registers live: 11 [11] 13 [13] 26 47 90
(note 228 76 265 1 [bb 1] NOTE_INSN_BASIC_BLOCK)

(insn 265 228 80 1 (set (reg/f:SI 2 2 [111])
        (plus:SI (reg/f:SI 13 13)
            (const_int 33216 [0x81c0]))) 40 {*i370.md:2127} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (const_int 33216 [0x81c0]))
        (nil)))

(insn 80 265 259 1 (set (mem/f:SI (reg/f:SI 2 2 [111]) [4 S4 A8])
        (const_int 0 [0x0])) 15 {movsi} (insn_list 265 (nil))
    (nil))

(insn 259 80 81 1 (set (reg/f:SI 9 9 [105])
        (plus:SI (reg/f:SI 13 13)
            (const_int 33212 [0x81bc]))) 40 {*i370.md:2127} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (const_int 33212 [0x81bc]))
        (nil)))

(insn 81 259 254 1 (set (mem/f:SI (reg/f:SI 9 9 [105]) [4 S4 A8])
        (const_int 0 [0x0])) 15 {movsi} (insn_list 259 (nil))
    (nil))

(insn 254 81 82 1 (set (reg/f:SI 8 8 [100])
        (plus:SI (reg/f:SI 13 13)
            (const_int 33208 [0x81b8]))) 40 {*i370.md:2127} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (const_int 33208 [0x81b8]))
        (nil)))

(insn 82 254 85 1 (set (mem/f:SI (reg/f:SI 8 8 [100]) [4 S4 A8])
        (const_int 0 [0x0])) 15 {movsi} (insn_list 254 (nil))
    (nil))

(note 85 82 86 1 NOTE_INSN_DELETED)

(insn 86 85 89 1 (set (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                (const_int 2 [0x2])) [0 S2 A16])
        (mem:HI (plus:SI (reg/f:SI 13 13)
                (const_int 127 [0x7f])) [0 S2 A8])) 16 {*i370.md:1004} (nil)
    (nil))

(note 89 86 90 1 NOTE_INSN_DELETED)

(insn 90 89 93 1 (set (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                (const_int 2 [0x2])) [0 S2 A16])
        (mem:HI (plus:SI (reg/f:SI 13 13)
                (const_int 129 [0x81])) [0 S2 A8])) 16 {*i370.md:1004} (nil)
    (nil))

(note 93 90 94 1 NOTE_INSN_DELETED)

(insn 94 93 96 1 (set (mem:QI (plus:SI (reg/f:SI 2 2 [111])
                (const_int 3 [0x3])) [0 S1 A8])
        (mem:QI (plus:SI (reg/f:SI 13 13)
                (const_int 131 [0x83])) [0 S1 A8])) 18 {*i370.md:1098} (nil)
    (nil))

(note 96 94 176 1 NOTE_INSN_LOOP_BEG)

(jump_insn 176 96 177 1 (set (pc)
        (label_ref 97)) 126 {jump} (nil)
    (nil))
;; End of basic block 1, registers live:
11 [11] 13 [13] 26 47 90 100 105

(barrier 177 176 175)

;; Start of basic block 2, registers live: 11 [11] 13 [13] 26 41 47 90 100 
105 106
(code_label 175 177 229 2 8 "" [1 uses])

(note 229 175 281 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 281 229 114 2 (set (reg:SI 2 2)
        (const_int 48 [0x30])) 15 {movsi} (nil)
    (nil))

(insn:QI 114 281 115 2 (set (cc0)
        (compare (reg/v:SI 6 6 [orig:41 cnt ] [41])
            (reg:SI 2 2))) 5 {cmpsi} (nil)
    (nil))

(jump_insn 115 114 230 2 (set (pc)
        (if_then_else (leu (cc0)
                (const_int 0 [0x0]))
            (label_ref 170)
            (pc))) 113 {bleu} (nil)
    (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil)))
;; End of basic block 2, registers live:
11 [11] 13 [13] 26 41 47 90 100 105 106

;; Start of basic block 3, registers live: 11 [11] 13 [13] 26 41 47 90 100 
105 106
(note 230 115 119 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 119 230 120 3 (set (reg:SI 3 3 [63])
        (const_int 33040 [0x8110])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (const_int 33040 [0x8110])
        (nil)))

(insn 120 119 121 3 (set (reg:QI 2 2 [orig:64 dscb1.ds1fmtid ] [64])
        (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 3 3 [63]))
                (const_int 156 [0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])) 18 
{*i370.md:1098} (insn_list 119 (nil))
    (expr_list:REG_EQUIV (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 3 3 [63]))
                (const_int 156 [0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])
        (expr_list:REG_EQUAL (mem/s:QI (plus:SI (reg/f:SI 13 13)
                    (const_int 33196 [0x81ac])) [0 dscb1.ds1fmtid+0 S1 A32])
            (nil))))

(insn:QI 121 120 122 3 (set (cc0)
        (compare (reg:QI 2 2 [orig:64 dscb1.ds1fmtid ] [64])
            (const_int -15 [0xfffffff1]))) 7 {*i370.md:517} (insn_list 120 
(nil))
    (nil))

(jump_insn 122 121 231 3 (set (pc)
        (if_then_else (ne (cc0)
                (const_int 0 [0x0]))
            (label_ref 170)
            (pc))) 105 {bne} (nil)
    (expr_list:REG_BR_PROB (const_int 8510 [0x213e])
        (nil)))
;; End of basic block 3, registers live:
11 [11] 13 [13] 26 41 47 63 90 100 105 106

;; Start of basic block 4, registers live: 11 [11] 13 [13] 26 41 47 63 90 
100 105 106
(note 231 122 282 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 282 231 127 4 (set (reg:QI 2 2)
        (const_int 64 [0x40])) 18 {*i370.md:1098} (nil)
    (nil))

(insn 127 282 283 4 (set (mem/s:QI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 3 3 [63]))
                (const_int 156 [0x9c])) [0 dscb1.ds1fmtid+0 S1 A32])
        (reg:QI 2 2)) 19 {movqi} (nil)
    (nil))

(insn 283 127 132 4 (set (reg:SI 3 3)
        (plus:SI (reg/f:SI 13 13)
            (const_int 32880 [0x8070]))) 40 {*i370.md:2127} (nil)
    (nil))

(insn 132 283 133 4 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (reg:SI 3 3)) 15 {movsi} (nil)
    (nil))

(call_insn 133 132 134 4 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("strlen") [flags 0x41] 
<function_decl 7b557c strlen>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 134 133 284 4 (set (reg:SI 15 15 [70])
        (reg:SI 15 15)) 15 {movsi} (insn_list 133 (nil))
    (nil))

(insn 284 134 139 4 (set (reg:SI 4 4)
        (plus:SI (reg/f:SI 13 13)
            (const_int 112 [0x70]))) 39 {*i370.md:2110} (nil)
    (nil))

(insn 139 284 285 4 (set (reg:SI 4 4)
        (plus:SI (reg:SI 4 4)
            (const_int 33040 [0x8110]))) 41 {addsi3} (insn_list 137 (nil))
    (nil))

(insn 285 139 140 4 (set (reg:SI 4 4)
        (reg:SI 4 4)) 15 {movsi} (nil)
    (nil))

(insn 140 285 286 4 (set (reg:SI 5 5 [orig:73+4 ] [73])
        (reg:SI 15 15 [70])) 15 {movsi} (insn_list 134 (insn_list 139 
(nil)))
    (nil))

(insn 286 140 143 4 (set (reg:SI 2 2)
        (plus:SI (reg/f:SI 13 13)
            (const_int 112 [0x70]))) 39 {*i370.md:2110} (nil)
    (nil))

(insn 143 286 287 4 (set (reg:SI 2 2)
        (plus:SI (reg:SI 2 2)
            (const_int 32768 [0x8000]))) 41 {addsi3} (insn_list 141 (nil))
    (nil))

(insn 287 143 144 4 (set (reg:SI 2 2)
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(insn 144 287 145 4 (set (reg:SI 3 3 [orig:74+4 ] [74])
        (reg:SI 15 15 [70])) 15 {movsi} (insn_list 143 (nil))
    (nil))

(insn 145 144 146 4 (parallel [
            (set (reg:SI 15 15 [66])
                (compare:SI (mem:BLK (reg:DI 4 4 [73]) [0 A8])
                    (mem:BLK (reg:DI 2 2 [74]) [0 A8])))
            (use (reg:DI 4 4 [73]))
            (use (reg:DI 2 2 [74]))
            (clobber (reg:DI 4 4 [73]))
            (clobber (reg:DI 2 2 [74]))
        ]) 12 {cmpmemsi_1} (insn_list 140 (insn_list 144 (nil)))
    (nil))

(insn:QI 146 145 147 4 (set (cc0)
        (reg:SI 15 15 [66])) 1 {tstsi} (insn_list 145 (nil))
    (nil))

(jump_insn 147 146 170 4 (set (pc)
        (if_then_else (eq (cc0)
                (const_int 0 [0x0]))
            (label_ref/s 268)
            (pc))) 104 {beq} (nil)
    (expr_list:REG_BR_PROB (const_int 500 [0x1f4])
        (nil)))
;; End of basic block 4, registers live:
11 [11] 13 [13] 26 41 47 66 90 100 105 106

;; Start of basic block 5, registers live: 11 [11] 13 [13] 26 47 90 100 105 
106
(code_label 170 147 235 5 5 "" [2 uses])

(note 235 170 172 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(note 172 235 288 5 NOTE_INSN_DELETED)

(insn 288 172 173 5 (set (reg:SI 2 2)
        (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 173 288 289 5 (set (reg:SI 2 2)
        (plus:SI (reg:SI 2 2)
            (const_int 1 [0x1]))) 41 {addsi3} (nil)
    (nil))

(insn 289 173 174 5 (set (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))
;; End of basic block 5, registers live:
11 [11] 13 [13] 26 47 90 100 105

(note 174 289 97 NOTE_INSN_LOOP_CONT)

;; Start of basic block 6, registers live: 11 [11] 13 [13] 26 47 90 100 105
(code_label 97 174 236 6 3 "" [1 uses])

(note 236 97 290 6 [bb 6] NOTE_INSN_BASIC_BLOCK)

(insn 290 236 98 6 (set (reg:SI 3 3)
        (mem/f:SI (reg/f:SI 11 11) [2 pdos+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 98 290 99 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (mem/s:SI (reg:SI 3 3) [4 <variable>.ipldev+0 S4 A32])) 15 {movsi} 
(nil)
    (nil))

(insn 99 98 100 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (mem/f:SI (reg/f:SI 8 8 [100]) [4 cyl+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 100 99 260 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 96 [0x60])) [0 S4 A32])
        (mem/f:SI (reg/f:SI 9 9 [105]) [4 head+0 S4 A32])) 15 {movsi} (nil)
    (nil))

(insn 260 100 101 6 (set (reg/f:SI 7 7 [106])
        (plus:SI (reg/f:SI 13 13)
            (const_int 33216 [0x81c0]))) 40 {*i370.md:2127} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (const_int 33216 [0x81c0]))
        (nil)))

(insn 101 260 291 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 100 [0x64])) [0 S4 A32])
        (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])) 15 {movsi} 
(insn_list 260 (nil))
    (nil))

(insn 291 101 103 6 (set (reg:SI 2 2)
        (reg/f:SI 13 13)) 15 {movsi} (nil)
    (nil))

(insn 103 291 292 6 (set (reg:SI 2 2)
        (plus:SI (reg:SI 2 2)
            (const_int 33152 [0x8180]))) 41 {addsi3} (nil)
    (nil))

(insn 292 103 104 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 104 [0x68])) [0 S4 A32])
        (reg:SI 2 2)) 15 {movsi} (nil)
    (nil))

(insn 104 292 105 6 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 108 [0x6c])) [0 S4 A32])
        (const_int 49 [0x31])) 15 {movsi} (nil)
    (nil))

(call_insn 105 104 106 6 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("rdblock") [flags 0x41] 
<function_decl 7bb21c rdblock>) [0 S1 A8])
            (const_int 24 [0x18]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 106 105 108 6 (set (reg/v:SI 6 6 [orig:41 cnt ] [41])
        (reg:SI 15 15)) 15 {movsi} (insn_list 105 (nil))
    (nil))

(insn:QI 108 106 109 6 (set (cc0)
        (reg/v:SI 6 6 [orig:41 cnt ] [41])) 1 {tstsi} (insn_list 106 (nil))
    (nil))

(jump_insn 109 108 180 6 (set (pc)
        (if_then_else (le (cc0)
                (const_int 0 [0x0]))
            (pc)
            (label_ref 175))) 122 {*i370.md:4516} (nil)
    (expr_list:REG_BR_PROB (const_int 9500 [0x251c])
        (nil)))
;; End of basic block 6, registers live:
11 [11] 13 [13] 26 41 47 90 100 105 106

(note 180 109 182 NOTE_INSN_LOOP_END)

;; Start of basic block 7, registers live: 11 [11] 13 [13] 41
(code_label 182 180 239 7 2 "" [2 uses])

(note 239 182 216 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(insn 216 239 184 7 (set (reg:SI 15 15 [orig:25 <result> ] [25])
        (const_int 0 [0x0])) 15 {movsi} (nil)
    (nil))

(insn:QI 184 216 185 7 (set (cc0)
        (reg/v:SI 6 6 [orig:41 cnt ] [41])) 1 {tstsi} (nil)
    (nil))

(jump_insn 185 184 240 7 (set (pc)
        (if_then_else (gt (cc0)
                (const_int 0 [0x0]))
            (label_ref 222)
            (pc))) 106 {bgt} (nil)
    (expr_list:REG_BR_PROB (const_int 9953 [0x26e1])
        (nil)))
;; End of basic block 7, registers live:
11 [11] 13 [13] 25

;; Start of basic block 8, registers live: 11 [11] 13 [13]
(note 240 185 189 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

(insn 189 240 190 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC4") [flags 0x2] <string_cst 7d4d48>)) 15 
{movsi} (nil)
    (nil))

(insn 190 189 191 8 (set (reg/f:SI 2 2 [84])
        (plus:SI (reg/f:SI 13 13)
            (const_int 32880 [0x8070]))) 40 {*i370.md:2127} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 13 13)
            (const_int 32880 [0x8070]))
        (nil)))

(insn 191 190 192 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg/f:SI 2 2 [84])) 15 {movsi} (insn_list 190 (nil))
    (nil))

(call_insn 192 191 195 8 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("printf") [flags 0x41] 
<function_decl 7729b4 printf>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 195 192 196 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (reg/f:SI 2 2 [84])) 15 {movsi} (nil)
    (nil))

(insn 196 195 197 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (const_int 64 [0x40])) 15 {movsi} (nil)
    (nil))

(call_insn 197 196 198 8 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("strchr") [flags 0x41] 
<function_decl 7b3654 strchr>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(note 198 197 199 8 NOTE_INSN_DELETED)

(insn 199 198 201 8 (set (mem:QI (reg:SI 15 15) [0 S1 A8])
        (const_int 0 [0x0])) 18 {*i370.md:1098} (insn_list 197 (nil))
    (nil))

(insn 201 199 203 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 88 [0x58])) [0 S4 A32])
        (symbol_ref/f:SI ("*LC5") [flags 0x2] <string_cst 7d4d98>)) 15 
{movsi} (nil)
    (nil))

(insn 203 201 204 8 (set (mem/f:SI (plus:SI (reg/f:SI 13 13)
                (const_int 92 [0x5c])) [0 S4 A32])
        (reg/f:SI 2 2 [84])) 15 {movsi} (nil)
    (nil))

(call_insn 204 203 209 8 (set (reg:SI 15 15)
        (call (mem:QI (symbol_ref/v:SI ("printf") [flags 0x41] 
<function_decl 7729b4 printf>) [0 S1 A8])
            (const_int 8 [0x8]))) 132 {*i370.md:4869} (nil)
    (nil)
    (nil))

(insn 209 204 210 8 (set (reg:SI 15 15 [orig:25 <result> ] [25])
        (const_int -1 [0xffffffff])) 15 {movsi} (nil)
    (expr_list:REG_EQUAL (const_int -1 [0xffffffff])
        (nil)))

(jump_insn 210 209 211 8 (set (pc)
        (label_ref 222)) 126 {jump} (nil)
    (nil))
;; End of basic block 8, registers live:
11 [11] 13 [13] 25

(barrier 211 210 268)

;; Start of basic block 9, registers live: 11 [11] 13 [13] 41 66 100 105 106
(code_label 268 211 232 9 10 "" [1 uses])

(note 232 268 151 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn 151 232 152 9 (set (mem/f:SI (reg/f:SI 9 9 [105]) [4 head+0 S4 A32])
        (reg:SI 15 15 [66])) 15 {movsi} (nil)
    (nil))

(insn 152 151 154 9 (set (mem/f:SI (reg/f:SI 8 8 [100]) [4 cyl+0 S4 A32])
        (reg:SI 15 15 [66])) 15 {movsi} (nil)
    (nil))

(insn 154 152 157 9 (set (mem/f:SI (reg/f:SI 7 7 [106]) [4 rec+0 S4 A32])
        (const_int 1 [0x1])) 15 {movsi} (nil)
    (nil))

(note 157 154 158 9 NOTE_INSN_DELETED)

(insn 158 157 159 9 (set (reg:SI 2 2 [79])
        (const_int 33085 [0x813d])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (const_int 33085 [0x813d])
        (nil)))

(insn 159 158 293 9 (set (reg:HI 2 2)
        (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 2 2 [79]))
                (const_int 112 [0x70])) [0 S2 A8])) 16 {*i370.md:1004} 
(insn_list 158 (nil))
    (nil))

(insn 293 159 162 9 (set (mem:HI (plus:SI (reg/f:SI 8 8 [100])
                (const_int 2 [0x2])) [0 S2 A16])
        (reg:HI 2 2)) 16 {*i370.md:1004} (nil)
    (nil))

(note 162 293 163 9 NOTE_INSN_DELETED)

(insn 163 162 164 9 (set (reg:SI 2 2 [82])
        (const_int 33087 [0x813f])) 15 {movsi} (nil)
    (expr_list:REG_EQUIV (const_int 33087 [0x813f])
        (nil)))

(insn 164 163 294 9 (set (reg:HI 2 2)
        (mem:HI (plus:SI (plus:SI (reg/f:SI 13 13)
                    (reg:SI 2 2 [82]))
                (const_int 112 [0x70])) [0 S2 A8])) 16 {*i370.md:1004} 
(insn_list 163 (nil))
    (nil))

(insn 294 164 166 9 (set (mem:HI (plus:SI (reg/f:SI 9 9 [105])
                (const_int 2 [0x2])) [0 S2 A16])
        (reg:HI 2 2)) 16 {*i370.md:1004} (nil)
    (nil))

(jump_insn 166 294 167 9 (set (pc)
        (label_ref 182)) 126 {jump} (nil)
    (nil))
;; End of basic block 9, registers live:
11 [11] 13 [13] 41

(barrier 167 166 220)

(note 220 167 222 NOTE_INSN_FUNCTION_END)

;; Start of basic block 10, registers live: 11 [11] 13 [13] 25
(code_label 222 220 243 10 1 "" [2 uses])

(note 243 222 223 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 223 243 226 10 (set (reg/i:SI 15 15 [ <result> ])
        (reg:SI 15 15 [orig:25 <result> ] [25])) 15 {movsi} (nil)
    (nil))

(insn 226 223 270 10 (use (reg/i:SI 15 15 [ <result> ])) -1 (insn_list 223 
(nil))
    (nil))
;; End of basic block 10, registers live:
11 [11] 13 [13] 15 [15]

(note 270 226 0 NOTE_INSN_DELETED)

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> Unfortunately it's not quite right, seemingly not loading R9 properly:
> 
> LR    9,13
> AR    9,13
> MVC   0(10,9),0(2)

That's weird.  What does the reload dump (.greg) say?
 
> And it had a knock-on effect too, producing bad code elsewhere:
> 
> <          SLR   2,2
> <          SLR   3,3
> <          ST    2,128(13)
> <          ST    3,4+128(13)
> <          ST    2,136(13)
> <          ST    3,4+136(13)
> <          ST    2,144(13)
> <          ST    3,4+144(13)
> ---
> >          MVC   128(8,13),=F'0'
> >          MVC   136(8,13),=F'0'
> >          MVC   144(8,13),=F'0'
> 
> But I guess that is another can of worms to investigate.

It seems the literal is not marked as being doubleword.  That might
be related to the fact that const_int's do not carry a mode, so you
cannot just look at the literal's mode to determine the required
size, but have to take the full instruction into account ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> You'll need to mark your new constraint as EXTRA_MEMORY_CONSTRAINT
> so that reload knows what to do when an argument doesn't match.

Thanks! That certainly produced an effect.

Unfortunately it's not quite right, seemingly not loading R9 properly:

LR    9,13
AR    9,13
MVC   0(10,9),0(2)

And it had a knock-on effect too, producing bad code elsewhere:

<          SLR   2,2
<          SLR   3,3
<          ST    2,128(13)
<          ST    3,4+128(13)
<          ST    2,136(13)
<          ST    3,4+136(13)
<          ST    2,144(13)
<          ST    3,4+144(13)
---
>          MVC   128(8,13),=F'0'
>          MVC   136(8,13),=F'0'
>          MVC   144(8,13),=F'0'

But I guess that is another can of worms to investigate.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> I was surprised that an instruction that is marked as s_operand
> was getting a seemingly non-s_operand given to it, so I added an
> "S" constraint:

That's right.  It is not good to have a constraint that accepts
more than the predicate, since reload will at this point only
consider the constraint.  Adding a more restricted constraint
should be the proper fix for this problem.

> That then gave an actual compiler error instead of generating bad
> code, which is a step forward:
> 
> pdos.c: In function `pdosLoadExe':
> pdos.c:2703: error: unable to generate reloads for:

You'll need to mark your new constraint as EXTRA_MEMORY_CONSTRAINT
so that reload knows what to do when an argument doesn't match.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi Ulrich and group.

The i370 port of GCC 3.4.6 is now complete and the result can be
downloaded from http://gccmvs.sourceforge.net

It can be built using configure/make, and there weren't that many
changes that needed to be made to the code to get it to work.

However, I have encountered a bug.

I get bad code generated for this, because a non-s_operand is
getting through:

; Move a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:BLK 0 "s_operand" "=m")
        (match_operand:BLK 1 "s_operand" "m"))
   (use (match_operand 2 "immediate_operand" "I"))]
  "((unsigned) INTVAL (operands[2]) < 256)"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 6, 0);
  return \"MVC  %O0(%c2,%R0),%1\";
}"
   [(set_attr "length" "6")]
)

Here is the bad code:

L     9,=F'32880'
MVC   9(10,13),0(2)

That "9" in the MVC is supposed to be a constant from 0-4095. It
can't fit the large value in so has used a register, but then tried
to use that register in the instruction. It should have added R13
to R9 and used that as the base register (instead of the 13
you see)

I was surprised that an instruction that is marked as s_operand
was getting a seemingly non-s_operand given to it, so I added an
"S" constraint:

; Move a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:BLK 0 "s_operand" "=S")
        (match_operand:BLK 1 "s_operand" "m"))

That then gave an actual compiler error instead of generating bad
code, which is a step forward:

pdos.c: In function `pdosLoadExe':
pdos.c:2703: error: unable to generate reloads for:
(insn 38 37 41 0 (parallel [
            (set (mem/s:BLK (plus:SI (reg/f:SI 13 13)
                        (const_int 32880 [0x8070])) [27 srchprog+0 S10 A64])
                (mem:BLK (reg/v/f:SI 2 2 [orig:27 prog ] [27]) [0 S10 A8]))
            (use (const_int 10 [0xa]))
        ]) 25 {*i370.md:1623} (insn_list 37 (nil))
    (expr_list:REG_DEAD (reg/v/f:SI 2 2 [orig:27 prog ] [27])
        (nil)))
pdos.c:2703: internal compiler error: in find_reloads, at reload.c:3690
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.


But I am surprised that s_operand and "S" are producing different
results.

Regardless, I sort of tracked the problem down to this bit of the
machine definition:

;
; movstrsi instruction pattern(s).
; block must be less than 16M (24 bits) in length

(define_expand "movstrsi"
  [(set (match_operand:BLK 0 "general_operand" "")
        (match_operand:BLK 1 "general_operand" ""))
   (use (match_operand:SI  2 "general_operand" ""))
   (match_operand 3 "" "")]
   ""
   "
{
  rtx op0, op1;

  op0 = XEXP (operands[0], 0);
  if (GET_CODE (op0) == REG
      || (GET_CODE (op0) == PLUS && GET_CODE (XEXP (op0, 0)) == REG
          && GET_CODE (XEXP (op0, 1)) == CONST_INT
          && (unsigned) INTVAL (XEXP (op0, 1)) < 4096))
    op0 = operands[0];
  else
    op0 = replace_equiv_address (operands[0], copy_to_mode_reg (SImode, 
op0));

  op1 = XEXP (operands[1], 0);
  if (GET_CODE (op1) == REG
      || (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1, 0)) == REG
          && GET_CODE (XEXP (op1, 1)) == CONST_INT
          && (unsigned) INTVAL (XEXP (op1, 1)) < 4096))
    op1 = operands[1];
  else
    op1 = replace_equiv_address (operands[1], copy_to_mode_reg (SImode, 
op1));

  if (GET_CODE (operands[2]) == CONST_INT && INTVAL (operands[2]) < 256)
    emit_insn (gen_rtx_PARALLEL (VOIDmode,
                        gen_rtvec (2,
                                   gen_rtx_SET (VOIDmode, op0, op1),
                                   gen_rtx_USE (VOIDmode, operands[2]))));


So now I am basically wanting to stop this code from doing that emit_insn.
I tested putting in a kludge to see if operands[2] was equal to 10 (the
length in my test case), and bypassing the emit_insn. That forced it to
use a more inefficient move instruction, but that's fine.

So I need some way of getting op0 detected as "unsuitable for use in
an MVC". I have put in debug and found that GET_CODE(op0) is equal
to MEM. I have also found that GET_CODE(XEXP(op0, 0)) is a REG_P,
whatever that means (I was just copying things I saw in the
s_operand test). Here is the s_operand test for reference:

/* Return 1 if OP is a valid S operand for an RS, SI or SS type instruction.
   OP is the current operation.
   MODE is the current operation mode.  */

int
s_operand (register rtx op, enum machine_mode mode)
{
  extern int volatile_ok;
  register enum rtx_code code = GET_CODE (op);

  if (CONSTANT_ADDRESS_P (op))
    return 1;
  if (mode == VOIDmode || GET_MODE (op) != mode)
    return 0;
  if (code == MEM)
    {
      register rtx x = XEXP (op, 0);

      if (!volatile_ok && op->volatil)
        return 0;
      if (REG_P (x) && REG_OK_FOR_BASE_P (x))
        return 1;
      if (GET_CODE (x) == PLUS
          && REG_P (XEXP (x, 0)) && REG_OK_FOR_BASE_P (XEXP (x, 0))
          && GET_CODE (XEXP (x, 1)) == CONST_INT
          && (unsigned) INTVAL (XEXP (x, 1)) < 4096)
        return 1;
    }
  return 0;
}

Now because I know that it is MEM and REG_P, I can actually
put in a check to detect that and abort it.

But that then causes more inefficient code to be generated
in other circumstances:

<          L     2,12(4)
<          MVC   104(24,13),0(2)
---
>          LA    4,104(,13)
>          LA    5,24(0,0)
>          L     2,12(6)
>          LR    3,5
>          MVCL  4,2

Any idea what can be done?

Thanks.  Paul.

Re: i370 port

[Paul Edwards]

>>> I think I would stop right there.  Why can't the i370 port support
>>> 64-bit integers?  Plenty of 32-bit hosts support them.
>>
>> It got an internal error.  I don't have the skills to get that to work,
>> but I do have the skills to bypass it one way or another (and I
>> demonstrated what I am doing now, but I know that that
>> intrusive code will break everything else, so want to back it out,
>> without losing the functionality that I want).
> 
> A failure in your target is not a reason to change target-independent
> code.

Well I found out what was causing this - the adddi3 definition.
Commenting that out allowed the target to be built the normal
way.

However, when doing the host build, I wanted everything done
by the (ansi) book so that I end up with code that can be compiled
with a C90 compiler, be it IBM's C/370 or Borland C++.

I found that I could achieve that by making my dummy cross-compile
script introduce the -ansi -pedantic-errors options.

However, that triggered off some more changes to configure like this ...

Index: gccnew/libiberty/configure
diff -c gccnew/libiberty/configure:1.1.1.3 gccnew/libiberty/configure:1.25
*** gccnew/libiberty/configure:1.1.1.3^ISun Nov 15 19:41:46 2009
--- gccnew/libiberty/configure^IWed Dec  2 17:18:07 2009
***************
*** 4190,4196 ****
  #if defined (__stub_$ac_func) || defined (__stub___$ac_func)
  choke me
  #else
! char (*f) () = $ac_func;
  #endif
  #ifdef __cplusplus
  }
--- 4190,4196 ----
  #if defined (__stub_$ac_func) || defined (__stub___$ac_func)
  choke me
  #else
! char (*f) () = (char (*)())$ac_func;
  #endif
  #ifdef __cplusplus
  }
***************
*** 4199,4205 ****
  int
  main ()
  {
! return f != $ac_func;
    ;
    return 0;
  }
--- 4199,4205 ----
  int
  main ()
  {
! return f != (char (*)())$ac_func;
    ;
    return 0;
  }


I still haven't found the wild pointer in my GCC 3.2.3 port that gets
masked with xcalloc.  It's a tough one because the problem keeps
on disappearing whenever I try to introduce debug info and I haven't
found a technique yet.

So I'm working on 3.2.3, 3.4.6 and 4.4 at any particular time.  :-)

BFN.  Paul..

Re: i370 port

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

> and c-parse.c:

That file no longer exists so I don't know how to interpret this.


>> I think I would stop right there.  Why can't the i370 port support
>> 64-bit integers?  Plenty of 32-bit hosts support them.
>
> It got an internal error.  I don't have the skills to get that to work,
> but I do have the skills to bypass it one way or another (and I
> demonstrated what I am doing now, but I know that that
> intrusive code will break everything else, so want to back it out,
> without losing the functionality that I want).

A failure in your target is not a reason to change target-independent
code.


> So would defining a new option be a reasonable solution for any
> target that wants to limit code generation for whatever reason?

No.

Ian

Re: i370 port

[Paul Edwards]

There are a couple of places where I need to do something different
if I'm running on an EBCDIC host (e.g. MVS, CMS, MUSIC, VSE).

So in mvspdp.h I have put:

/* If running on MVS, need some EBCDIC-related differences */
#if defined(__MVS__) || defined(__CMS__)
#define HOST_EBCDIC 1
#endif

and c-parse.c:

#ifdef HOST_EBCDIC
#define YYTRANSLATE(YYX)                      \
  ((unsigned int) (YYX) <= YYMAXUTOK ? \
  ((unsigned int) (YYX) < 256 ? yytranslate[_sch_ebcasc[YYX]] \
  : yytranslate[YYX]) : YYUNDEFTOK)
#else
#define YYTRANSLATE(YYX) ^I^I^I^I^I^I\
  ((unsigned int) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK)
#endif

and opts.c:

#ifdef HOST_EBCDIC
static size_t
find_opt (const char *input, int lang_mask)
{
/* sequential search */


Is that a reasonable way to do it?

I think I should probably make the opts.c into a PUREISO so that
the sequential search is always used (ie work on an arbitrary C90
platform, not necessarily ASCII or EBCDIC).

But the c-parse one is definitely a translation that will only work
on EBCDIC.  That is useful so that I don't need to have a working
bison.  Similarly, the opts.c change doesn't require a working
shell!

> I think I would stop right there.  Why can't the i370 port support
> 64-bit integers?  Plenty of 32-bit hosts support them.

It got an internal error.  I don't have the skills to get that to work,
but I do have the skills to bypass it one way or another (and I
demonstrated what I am doing now, but I know that that
intrusive code will break everything else, so want to back it out,
without losing the functionality that I want).

> That said, these days gcc always defines __SIZEOF_LONG_LONG__.  It
> would be perfectly reasonable for hwint.h to test that.  Maybe
> something along the lines of
> 
> #if !defined HAVE_LONG_LONG
> # if GCC_VERSION >= 3000
> #  ifdef __SIZEOF_LONG_LONG__
> #    define HAVE_LONG_LONG 1
> #    define SIZEOF_LONGLONG __SIZEOF_LONG_LONG__
> #  else
> #   define HAVE_LONG_LONG 1
> #   define SIZEOF_LONG_LONG 8

These both switch long_long on.  I want to switch it off (which it was
already).

> extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
> #  endif
> # endif
> #endif

So would defining a new option be a reasonable solution for any
target that wants to limit code generation for whatever reason?

Thanks.  Paul.

Re: i370 port

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

> Another "where" question.  The i370 port can't cope with 64-bit
> integers.

I think I would stop right there.  Why can't the i370 port support
64-bit integers?  Plenty of 32-bit hosts support them.

That said, these days gcc always defines __SIZEOF_LONG_LONG__.  It
would be perfectly reasonable for hwint.h to test that.  Maybe
something along the lines of

#if !defined HAVE_LONG_LONG
# if GCC_VERSION >= 3000
#  ifdef __SIZEOF_LONG_LONG__
#    define HAVE_LONG_LONG 1
#    define SIZEOF_LONGLONG __SIZEOF_LONG_LONG__
#  else
#   define HAVE_LONG_LONG 1
#   define SIZEOF_LONG_LONG 8
extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
#  endif
# endif
#endif


Ian

Re: i370 port

[Paul Edwards]

> I can see that ansidecl.h is a tempting place to put this, but I don't
> think it is correct.  ansidecl.h is used by many different programs,
> including the GNU binutils and gdb.  Changes that are specific to gcc
> should be in gcc, probably in gcc/system.h.  Changes specific to
> libiberty should be in libiberty, probably in include/libiberty.h.

Another "where" question.  The i370 port can't cope with 64-bit
integers.  The below bit keeps on defining it.  So I created a
WANT64 which obviously is never going to be set.

I've just updated config/i370/mvspdp.h to define
USE_C_ALLOCA
because the i370 also doesn't have this builtin.  I was wondering
if I could define another variable, USE_ONLY32, to achieve the
same thing for the 64-bit integers.

PUREISO (I'll change it to C90 later when everything is working)
is not always going to be true for the pdp port.  By default, someone
extracting the modified 3.4.6 code will in fact get a non-C90 build
and it will have the traditional separate gcc, cc1 etc modules.  So
I can't use that.

So - is USE_ONLY32 the way to go or is there another method?

Thanks.  Paul.




C:\devel\gccnew\gcc>cvs diff -c hwint.h
Index: hwint.h
===================================================================
RCS file: c:\cvsroot/gccnew/gcc/hwint.h,v
retrieving revision 1.2
diff -c -r1.2 hwint.h
*** hwint.h     24 Apr 2009 14:27:58 -0000      1.2
--- hwint.h     10 Nov 2009 13:38:16 -0000
***************
*** 22,28 ****
     but they're all cross-compile-only.)  Just in case, force a
     constraint violation if that assumption is incorrect.  */
  #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO
  #  define HAVE_LONG_LONG 1
  #  define SIZEOF_LONG_LONG 8
  extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
--- 22,28 ----
     but they're all cross-compile-only.)  Just in case, force a
     constraint violation if that assumption is incorrect.  */
  #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO && defined(WANT64)
  #  define HAVE_LONG_LONG 1
  #  define SIZEOF_LONG_LONG 8
  extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];

Re: i370 port

[Paul Edwards]

>> Now all code needs to be exposed to this.  ie libiberty and
>> gcc.  To fit in with the new style of building, I basically want
>> to update ansidecl.h to do a:
>>
>> #ifdef PUREISO
>> #include "mshort.h"
>> #endif
>>
>> Does that seem reasonable?
> 
> The ISO C99 standard requires that an identifier have 31 significant
> initial characters, so PUREISO does not seem like the right name here.

Ok.  I was under the impression that C99 was rarely fully
implemented, and far from universal, thus pretty irrelevant.

> Based on your suggested #define's, your system seems even more
> restrictive than ISO C99 requires.  I vaguely recall that ISO C90
> requires 6 significant initial characters, so something like

Yep, externals need to be unique in the first 6 characters, and
with case ignored.  My system requires 8, and ignores case.

> PURE_ISO_C90 might be right here.

Ok.

> I can see that ansidecl.h is a tempting place to put this, but I don't
> think it is correct.  ansidecl.h is used by many different programs,
> including the GNU binutils and gdb.

Ok, but it's a non-default option, so would have no effect on those.

> Changes that are specific to gcc
> should be in gcc, probably in gcc/system.h.  Changes specific to
> libiberty should be in libiberty, probably in include/libiberty.h.

I can give it a go, but I'm not sure they kick in early enough.  I
even had to move the ansidecl in cplus-dem.c up to get it to
take effect soon enough.

But in principle, separating the remaps for libiberty and gcc into
two different files sounds like the correct thing to be doing, so
I'll see if I can get that to work.  Needs a bit more infrastructure
to be written though.  :-)

BFN.  Paul.

Re: i370 port

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

> Now all code needs to be exposed to this.  ie libiberty and
> gcc.  To fit in with the new style of building, I basically want
> to update ansidecl.h to do a:
>
> #ifdef PUREISO
> #include "mshort.h"
> #endif
>
> Does that seem reasonable?

The ISO C99 standard requires that an identifier have 31 significant
initial characters, so PUREISO does not seem like the right name here.
Based on your suggested #define's, your system seems even more
restrictive than ISO C99 requires.  I vaguely recall that ISO C90
requires 6 significant initial characters, so something like
PURE_ISO_C90 might be right here.

I can see that ansidecl.h is a tempting place to put this, but I don't
think it is correct.  ansidecl.h is used by many different programs,
including the GNU binutils and gdb.  Changes that are specific to gcc
should be in gcc, probably in gcc/system.h.  Changes specific to
libiberty should be in libiberty, probably in include/libiberty.h.

Ian

Re: i370 port

[Paul Edwards]

Still making great progress.

The process is being simplified.

I have a question.  I need to remap long names to short, and I
wish to use #defines to do this as it is portable.

So I have a whole lot of:

#define align_functions ZZZ_1
#define align_functions_log ZZZ_2

etc

and I have put them all into an mshort.h for convenience.

Now all code needs to be exposed to this.  ie libiberty and
gcc.  To fit in with the new style of building, I basically want
to update ansidecl.h to do a:

#ifdef PUREISO
#include "mshort.h"
#endif

Does that seem reasonable?

Actually I also need to #include "unixio.h" to include various
types that must be present, st_ino or whatever too.

I may have other miscellaneous defines as well.  I'm still in
the process of unwinding all the hacks I put in years ago.  :-)

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> The QI must be a signed char, and thus rejecting any value greater than 127.
> As you can see, I changed it to SI, which, with the constraints and tests
> in place, should be fine.

Ah, OK.  That would explain it.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
>> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
>> ../include
>>          varasm.c
>> (insn 117 429 118 7 (parallel [
>>             (set (reg:SI 64)
>>                 (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21
>> virtual-stack-vars)
>>
>>                             (const_int 456 [0x1c8])) [232 value+0 S196 
>> A64])
>>                     (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
>>                             (const_int 8 [0x8])) [0 A8])))
>>             (use (const_int 196 [0xc4]))
>>         ]) -1 (nil)
>>     (nil))
>> varasm.c: In function `force_const_mem':
>> varasm.c:3021: internal compiler error: in 
>> instantiate_virtual_regs_lossage,
>> at function.c:3767
>
> OK, so what goes on here is that GCC attempts to replace the "virtual"
> register 21 (virtual-stack-vars) with some real register, that is
> frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
> this should resolve to
>  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size
>
> Overall, the middle-end would therefore replace "reg 21 + 456" with
> "reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
> + current_function_outgoing_args_size.
>
> It will then re-process the insn pattern constraints to verify that the
> resulting insn is still valid.  At this stage, it appears we're running
> into the above error.  I'm not quite sure why this would be case, this
> will require some further debugging why the insn was not recognized ...

This mystery is finally solved.

The previous workaround I had in place failed when I tried to do an
unoptimized compile of varasm.c.  I found this out when I tried speeding
up the experimental configure/make process.  However, since it was
occurring with unoptimized compiles, I thought it would be easier to
track down, and indeed, I found out that the memcmp was only
failing for values 128 and above. 127 was working fine.  That made me
suspect a signed char vs unsigned char problem.

And it's the "QI" below that was causing the grief ...

*** 699,711 ****
      {
        op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
      }
!
!   /* one circumstance has been found where this short comparison
!      causes an internal error. Could be related to the fact that
!      both displacements were non-zero, which is unusual. So check
!      for that */
!   if (((iv1 == 0) || (iv2 == 0)) &&
!       GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
      {
        emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
                gen_rtx_SET (VOIDmode, operands[0],
--- 697,705 ----
      {
        op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
      }
!
!   if (GET_CODE (operands[3]) == CONST_INT
!       && (unsigned)INTVAL (operands[3]) < 256)
      {
        emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
                gen_rtx_SET (VOIDmode, operands[0],
***************
*** 747,753 ****
    [(set (match_operand:SI 0 "register_operand" "=d")
        (compare:SI (match_operand:BLK 1 "s_operand" "m")
                 (match_operand:BLK 2 "s_operand" "m")))
!    (use (match_operand:QI 3 "immediate_operand" "I"))]
    "((unsigned) INTVAL (operands[3]) < 256)"
    "*
  {
--- 741,747 ----
    [(set (match_operand:SI 0 "register_operand" "=d")
        (compare:SI (match_operand:BLK 1 "s_operand" "m")
                 (match_operand:BLK 2 "s_operand" "m")))
!    (use (match_operand:SI 3 "immediate_operand" "I"))]
    "((unsigned) INTVAL (operands[3]) < 256)"
    "*
  {

The QI must be a signed char, and thus rejecting any value greater than 127.
As you can see, I changed it to SI, which, with the constraints and tests
in place, should be fine.

Just to be sure, I did a before and after comparison of the generated
assembler for all of GCC (3.4.6) and it all checked out fine.  :-)

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> As such, it's appropriate to simply comment it out (which was my
> "workaround").  However, before I do so, do you think this is close
> to being correct?  I already made one correction, to put in that
> XL1 rather than doing a fullword (which was always zero obviously).
> 
> 
> (define_insn "movstrictqi"
>   [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d"))
>   (match_operand:QI 1 "general_operand" "g"))]
>   ""
>   "*
> {
>   check_label_emit ();
>   if (REG_P (operands[1]))
>     {
>       mvs_check_page (0, 8, 0);
>       return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\";
>     }
>   mvs_check_page (0, 4, 0);
>   return \"IC^I%0,=XL1'%X1'\";
> }"
>    [(set_attr "length" "8")]
> )

The one obvious problem I see with this pattern is that the predicate
and constraint for operand 1 allow register, immediate and *memory*
operands, but the body seems to only handle register and immediate
operands correctly.

The STC followed by IC is of course correct, but will cause significant
penalities on all modern machines.  Just about any other way to load
the low byte (e.g. and with mask, then or) would be more efficient ...


> Which I can clearly see is different.  Specifically, the IC by itself is 
> fine,
> although I would have preferred to see the LA instruction there, but for
> some reason it is dropping the CLR.  That makes it technically
> incorrect.

This is odd.  I don't quite see why this would happen.  You should look
into the RTL dump files generated via -da to see where the compare insn
disappears ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Ulrich, here's one of the workarounds I mentioned.  The other one is
pretty similar to this one as well.

After my investigation, I've come to the conclusion that this never
worked, and was not noticed before, because the optimizer mustn't
have ever used it before.

As such, it's appropriate to simply comment it out (which was my
"workaround").  However, before I do so, do you think this is close
to being correct?  I already made one correction, to put in that
XL1 rather than doing a fullword (which was always zero obviously).


(define_insn "movstrictqi"
  [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d"))
  (match_operand:QI 1 "general_operand" "g"))]
  ""
  "*
{
  check_label_emit ();
  if (REG_P (operands[1]))
    {
      mvs_check_page (0, 8, 0);
      return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\";
    }
  mvs_check_page (0, 4, 0);
  return \"IC^I%0,=XL1'%X1'\";
}"
   [(set_attr "length" "8")]
)


The trouble is that when the instruction is active, things like this
happen:

C:\devel\gccnew\gcc>diff -c6 old\alias.s new\alias.s | head -50
*** old\alias.s Tue Sep 22 09:37:45 2009
--- new\alias.s Fri Sep 25 16:38:31 2009
***************
*** 277,290 ****
  L26      EQU   *
           N     2,=XL4'000000FF'
           LA    3,242(0,0)
           CR    2,3
           BE    L30
           BH    L45
!          LA    3,241(0,0)
!          CLR   2,3
           BE    L28
           B     L44
  L45      EQU   *
           LA    3,243(0,0)
           CLR   2,3
           BE    L37
--- 277,289 ----
  L26      EQU   *
           N     2,=XL4'000000FF'
           LA    3,242(0,0)
           CR    2,3
           BE    L30
           BH    L45
!          IC    3,=XL1'F1'
           BE    L28
           B     L44
  L45      EQU   *
           LA    3,243(0,0)
           CLR   2,3
           BE    L37

Which I can clearly see is different.  Specifically, the IC by itself is 
fine,
although I would have preferred to see the LA instruction there, but for
some reason it is dropping the CLR.  That makes it technically
incorrect.

I checked the S/370 reference summary, and IC doesn't set the condition
code, and nor does the instruction pattern mention condition codes
anywhere.  Normally I would be suspicious of the rest of the compiler,
but in this case, I know that the compiler is stable and the i370
target is dubious.  :-)

After resolution of this one way or another, I think it's in a good enough
state for version 1.0 and will start on the preparations for all that.

BFN.  Paul.

Re: i370 port

[Paul Edwards]

> I have a theory that if both displacements in the S-type (ie register plus
> displacement) address are non-zero, that something fails.  So the
> next thing I will do is see if I can detect just that situation, and stop
> it going into the CLC.

I now have that detection in place, and done a self-compile, and all
is looking great.  No idea if that is producing a technically correct
compiler or not though (ie whether my workaround correctly
bypasses all circumstances).

So that leaves 2 more workarounds which I would like to reverse
out.  I'll spend some time on them next.

BFN.  Paul.




;
; cmpmemsi instruction pattern(s).
;

(define_expand "cmpmemsi"
  [(set (match_operand:SI 0 "general_operand" "")
   (compare (match_operand:BLK 1 "general_operand" "")
     (match_operand:BLK 2 "general_operand" "")))
     (use (match_operand:SI 3 "general_operand" ""))
     (use (match_operand:SI 4 "" ""))]
   ""
   "
{
  rtx op1, op2;
  int iv1 = 0;
  int iv2 = 0;

  op1 = XEXP (operands[1], 0);
  if (GET_CODE (op1) == REG
      || (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1, 0)) == REG
   && GET_CODE (XEXP (op1, 1)) == CONST_INT
   && (unsigned) (iv1 = INTVAL (XEXP (op1, 1))) < 4096))
    {
      op1 = operands[1];
    }
  else
    {
      op1 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op1));
    }

  op2 = XEXP (operands[2], 0);
  if (GET_CODE (op2) == REG
      || (GET_CODE (op2) == PLUS && GET_CODE (XEXP (op2, 0)) == REG
   && GET_CODE (XEXP (op2, 1)) == CONST_INT
   && (unsigned) (iv2 = INTVAL (XEXP (op2, 1))) < 4096))
    {
      op2 = operands[2];
    }
  else
    {
      op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
    }

  /* one circumstance has been found where this short comparison
     causes an internal error. Could be related to the fact that
     both displacements were non-zero, which is unusual. So check
     for that */
  if (((iv1 == 0) || (iv2 == 0)) &&
      GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
    {
      emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
  gen_rtx_SET (VOIDmode, operands[0],
   gen_rtx_COMPARE (SImode, op1, op2)), /* was VOIDmode */
  gen_rtx_USE (VOIDmode, operands[3]))));
    }
  else
    {
        /* implementation suggested by  Richard Henderson <rth@cygnus.com> 
*/
        rtx reg1 = gen_reg_rtx (DImode);
        rtx reg2 = gen_reg_rtx (DImode);
        rtx result = operands[0];
        rtx mem1 = operands[1];
        rtx mem2 = operands[2];
        rtx len = operands[3];
        if (!CONSTANT_P (len))
          len = force_reg (SImode, len);

        /* Load up the address+length pairs.  */
        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
                        force_operand (XEXP (mem1, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)), len);

        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
                        force_operand (XEXP (mem2, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)), len);

        /* Compare! */
        emit_insn (gen_cmpmemsi_1 (result, reg1, reg2));
    }
  DONE;
}")

; Compare a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
 (compare:SI (match_operand:BLK 1 "s_operand" "m")
   (match_operand:BLK 2 "s_operand" "m")))
   (use (match_operand:QI 3 "immediate_operand" "I"))]
  "((unsigned) INTVAL (operands[3]) < 256)"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 22, 0);
  return \"CLC %O1(%c3,%R1),%2\;BH *+12\;BL *+6\;SLR %0,%0\;LNR %0,%0\";
}"
   [(set_attr "length" "22")]
)

; Compare a block that is larger than 255 bytes in length.
;        (mem:BLK (subreg:SI (match_operand:DI 1 "register_operand" "+d") 
0))
;        (mem:BLK (subreg:SI (match_operand:DI 2 "register_operand" "+d") 
0))))

(define_insn "cmpmemsi_1"
  [(set (match_operand:SI 0 "register_operand" "+d")
        (compare:SI
        (mem:BLK (match_operand:DI 1 "register_operand" "+d") )
        (mem:BLK (match_operand:DI 2 "register_operand" "+d") )))
   (use (match_dup 1))
   (use (match_dup 2))
   (clobber (match_dup 1))
   (clobber (match_dup 2))]
  ""
  "*
{
  check_label_emit ();
  mvs_check_page (0, 18, 0);
  return \"LA %0,1(0,0)\;CLCL %1,%2\;BH *+12\;BL *+6\;SLR %0,%0\;LNR 
%0,%0\";
}"
   [(set_attr "length" "18")]
)

Re: i370 port

[Paul Edwards]

>> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
>> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
>> ../include
>>          varasm.c
>> (insn 117 429 118 7 (parallel [
>>             (set (reg:SI 64)
>>                 (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21
>> virtual-stack-vars)
>>
>>                             (const_int 456 [0x1c8])) [232 value+0 S196 
>> A64])
>>                     (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
>>                             (const_int 8 [0x8])) [0 A8])))
>>             (use (const_int 196 [0xc4]))
>>         ]) -1 (nil)
>>     (nil))
>> varasm.c: In function `force_const_mem':
>> varasm.c:3021: internal compiler error: in 
>> instantiate_virtual_regs_lossage,
>> at function.c:3767
>
> OK, so what goes on here is that GCC attempts to replace the "virtual"
> register 21 (virtual-stack-vars) with some real register, that is
> frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
> this should resolve to
>  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size
>
> Overall, the middle-end would therefore replace "reg 21 + 456" with
> "reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
> + current_function_outgoing_args_size.
>
> It will then re-process the insn pattern constraints to verify that the
> resulting insn is still valid.  At this stage, it appears we're running
> into the above error.  I'm not quite sure why this would be case, this
> will require some further debugging why the insn was not recognized ...

Ok, I spent today trying to solve this problem.  Although I didn't succeed
in solving it properly, I did at least find a workaround for the one 
instance.
I found that in the failing circumstance, neither of the two things being
compared fell into the "force copy" situation.  I don't know whether that
is right or wrong, but at least I can detect whether a "force copy" was
done.  If no force copy was done, I stop doing the short CLC and let
it do the CLCL instead.  See below where I have introduced the "copy"
variable.  Unfortunately it affects other things, ie good CLCs have been
converted into CLCL also, which is a shame.  However, it may at least
mean the compiler doesn't have a bug as far as the end user is
concerned, ie it generates valid code.

I have a theory that if both displacements in the S-type (ie register plus
displacement) address are non-zero, that something fails.  So the
next thing I will do is see if I can detect just that situation, and stop
it going into the CLC.

Some of these md constructs are beginning to make more sense.  :-)

BFN.  Paul.



;
; cmpmemsi instruction pattern(s).
;

(define_expand "cmpmemsi"
  [(set (match_operand:SI 0 "general_operand" "")
   (compare (match_operand:BLK 1 "general_operand" "")
     (match_operand:BLK 2 "general_operand" "")))
     (use (match_operand:SI 3 "general_operand" ""))
     (use (match_operand:SI 4 "" ""))]
   ""
   "
{
  rtx op1, op2;
  int copy = 0;

  op1 = XEXP (operands[1], 0);
  if (GET_CODE (op1) == REG
      || (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1, 0)) == REG
   && GET_CODE (XEXP (op1, 1)) == CONST_INT
   && (unsigned) INTVAL (XEXP (op1, 1)) < 4096))
    {
      op1 = operands[1];
    }
  else
    {
      op1 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op1));
      copy = 1;
    }

  op2 = XEXP (operands[2], 0);
  if (GET_CODE (op2) == REG
      || (GET_CODE (op2) == PLUS && GET_CODE (XEXP (op2, 0)) == REG
   && GET_CODE (XEXP (op2, 1)) == CONST_INT
   && (unsigned) INTVAL (XEXP (op2, 1)) < 4096))
    {
      op2 = operands[2];
    }
  else
    {
      op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
      copy = 1;
    }

  /* so long as at least one operand was copied, this seems safe */
  if (copy &&
      GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
    {
      emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
  gen_rtx_SET (VOIDmode, operands[0],
   gen_rtx_COMPARE (SImode, op1, op2)), /* was VOIDmode */
  gen_rtx_USE (VOIDmode, operands[3]))));
    }
  else
    {
        /* implementation suggested by  Richard Henderson <rth@cygnus.com> 
*/
        rtx reg1 = gen_reg_rtx (DImode);
        rtx reg2 = gen_reg_rtx (DImode);
        rtx result = operands[0];
        rtx mem1 = operands[1];
        rtx mem2 = operands[2];
        rtx len = operands[3];
        if (!CONSTANT_P (len))
          len = force_reg (SImode, len);

        /* Load up the address+length pairs.  */
        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
                        force_operand (XEXP (mem1, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)), len);

        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
                        force_operand (XEXP (mem2, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)), len);

        /* Compare! */
        emit_insn (gen_cmpmemsi_1 (result, reg1, reg2));
    }
  DONE;
}")

; Compare a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
 (compare:SI (match_operand:BLK 1 "s_operand" "m")
   (match_operand:BLK 2 "s_operand" "m")))
   (use (match_operand:QI 3 "immediate_operand" "I"))]
  "((unsigned) INTVAL (operands[3]) < 256)"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 22, 0);
  return \"CLC %O1(%c3,%R1),%2\;BH *+12\;BL *+6\;SLR %0,%0\;LNR %0,%0\";
}"
   [(set_attr "length" "22")]
)

; Compare a block that is larger than 255 bytes in length.
;        (mem:BLK (subreg:SI (match_operand:DI 1 "register_operand" "+d") 
0))
;        (mem:BLK (subreg:SI (match_operand:DI 2 "register_operand" "+d") 
0))))

(define_insn "cmpmemsi_1"
  [(set (match_operand:SI 0 "register_operand" "+d")
        (compare:SI
        (mem:BLK (match_operand:DI 1 "register_operand" "+d") )
        (mem:BLK (match_operand:DI 2 "register_operand" "+d") )))
   (use (match_dup 1))
   (use (match_dup 2))
   (clobber (match_dup 1))
   (clobber (match_dup 2))]
  ""
  "*
{
  check_label_emit ();
  mvs_check_page (0, 18, 0);
  return \"LA %0,1(0,0)\;CLCL %1,%2\;BH *+12\;BL *+6\;SLR %0,%0\;LNR 
%0,%0\";
}"
   [(set_attr "length" "18")]
)

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>          varasm.c
> (insn 117 429 118 7 (parallel [
>             (set (reg:SI 64)
>                 (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
> virtual-stack-vars)
> 
>                             (const_int 456 [0x1c8])) [232 value+0 S196 A64])
>                     (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
>                             (const_int 8 [0x8])) [0 A8])))
>             (use (const_int 196 [0xc4]))
>         ]) -1 (nil)
>     (nil))
> varasm.c: In function `force_const_mem':
> varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
> at function.c:3767

OK, so what goes on here is that GCC attempts to replace the "virtual"
register 21 (virtual-stack-vars) with some real register, that is
frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
this should resolve to
  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size

Overall, the middle-end would therefore replace "reg 21 + 456" with 
"reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
+ current_function_outgoing_args_size.

It will then re-process the insn pattern constraints to verify that the
resulting insn is still valid.  At this stage, it appears we're running
into the above error.  I'm not quite sure why this would be case, this
will require some further debugging why the insn was not recognized ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> That's a bit hard to diagnose without some further information ...
>
> What insn it is failing on?  (To find out, use a debugger, or maybe
> add a "debug_rtx (insn)" statement before the abort in
> instantiate_virtual_regs_lossage)?

I did the latter.

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include
         varasm.c
(insn 117 429 118 7 (parallel [
            (set (reg:SI 64)
                (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
virtual-stack-vars)

                            (const_int 456 [0x1c8])) [232 value+0 S196 A64])
                    (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
                            (const_int 8 [0x8])) [0 A8])))
            (use (const_int 196 [0xc4]))
        ]) -1 (nil)
    (nil))
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
at
function.c:3767
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.


Which would seem to correspond to this:

; Compare a block that is less than 256 bytes in length.

(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
^I(compare:SI (match_operand:BLK 1 "s_operand" "m")
^I^I (match_operand:BLK 2 "s_operand" "m")))
   (use (match_operand:QI 3 "immediate_operand" "I"))]
  "((unsigned) INTVAL (operands[3]) < 256)"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 22, 0);
  return 
\"CLC^I%O1(%c3,%R1),%2\;BH^I*+12\;BL^I*+6\;SLR^I%0,%0\;LNR^I%0,%0\";
}"
   [(set_attr "length" "22")]
)


> This is conceivably another effect of the same bug, but again it's
> hard to say.  You'd have to look at the generated RTX and see how
> it changes over the various optimization stages (use -da to generate
> RTX dumps after each stage).

Ok, I'll see if I can see something.  Probably easier for me to play
around with the md though.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> And as I mentioned, there's just one real bug that I know of left.  I can
> bypass the bug in the GCC code that I am compiling, by forcing a
> function call.
> 
> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>          varasm.c
> varasm.c: In function `force_const_mem':
> varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
> at
> function.c:3765
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gccmvs.sourceforge.net> for instructions.

That's a bit hard to diagnose without some further information ...

What insn it is failing on?  (To find out, use a debugger, or maybe
add a "debug_rtx (insn)" statement before the abort in 
instantiate_virtual_regs_lossage)?

> which is bizarre.  It seems to be comparing two values that are 8 bytes
> apart, for a length of 196.  Can't imagine that doing anything useful.

This is conceivably another effect of the same bug, but again it's
hard to say.  You'd have to look at the generated RTX and see how
it changes over the various optimization stages (use -da to generate
RTX dumps after each stage).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> > As an alternative to the operand predicate, you might also add
>> > an extra check to the insn condition.  For example, something
>> > along the following lines should work:
>> >
>> > (define_insn ""
>> >   [(set (match_operand:SI 0 "register_operand" "=d")
>> >         (mult:SI (match_operand:SI 1 "register_operand" "0")
>> >                  (match_operand:SI 2 "const_int_operand" "K")))]
>> >   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
>>
>> My eyes lit up when I saw that!  However, it produced a compiler
>> error when I tried it.  But undeterred, I tried this:

Sorry.  I just copied the last line into the existing pattern, didn't
notice that you'd changed the predicate too.

>> (define_insn ""
>>   [(set (match_operand:SI 0 "register_operand" "=d")
>>         (mult:SI (match_operand:SI 1 "register_operand" "0")
>>                  (match_operand:SI 2 "immediate_operand" "K")))]
>>   "(GET_CODE (operands[2]) == CONST_INT
>>    && REG_P (operands[0])
>>    && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"
>
> Huh.  Instead of adding an explicit CONST_INT check, my approach
> above used a const_int_operand predicate (instead of immediate_operand).
> That should have had the exact same effect ...   I'm not sure why the
> REG_P check on the other operand would be necessary at this point.

I just copied that from the existing condition too.  Once I realised
that I could put a check in advance, I just copied the check
across basically.  I'd seen that before, it just hadn't sunk in that
I could use it for this situation.

I will try out your original suggestion again properly.  :-)

>> And it worked (verified by self-compile)!  And I relaxed the
>> constraint on the "M" instruction as well.  Those old warnings
>> are apparently irrelevant now.  Thank you sir.  :-)
>
> OK, that's good to know.

Indeed.

And as I mentioned, there's just one real bug that I know of left.  I can
bypass the bug in the GCC code that I am compiling, by forcing a
function call.

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include
         varasm.c
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
at
function.c:3765
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.

This is the code that is triggering off that bug:

force_const_mem (enum machine_mode mode, rtx x)
{
  int hash;
  struct constant_descriptor_rtx *desc;
...
    if (compare_constant_rtx (mode, x, desc))


static int
compare_constant_rtx (enum machine_mode mode, rtx x,
^I^I      struct constant_descriptor_rtx *desc)
{
  struct rtx_const value;

  decode_rtx_const (mode, x, &value);

  /* Compare constant contents.  */
#if defined(XTARGET_MVS) /* +++ seems we have a machine definition problem 
*/
  return (memcmp) (&value, &desc->value, sizeof (struct rtx_const)) == 0;
#else
  return memcmp (&value, &desc->value, sizeof (struct rtx_const)) == 0;
#endif
}


You can see how I normally work around this problem by forcing a
function call.

If I do that force, then I get this code generated:

L445     EQU   *
         LTR   3,3
         BE    L442
         MVC   88(4,13),0(11)
         MVC   92(4,13),4(11)
         LA    2,560(,13)
         ST    2,96(13)
         LA    1,88(,13)
         L     15,=A(@@F17)
         BALR  14,15
         ST    2,88(13)
         LR    2,3
         A     2,=F'8'
         ST    2,92(13)
         MVC   96(4,13),=F'196'
         LA    1,88(,13)
         L     15,=V(MEMCMP)
         BALR  14,15
         LTR   15,15

which is bizarre.  It seems to be comparing two values that are 8 bytes
apart, for a length of 196.  Can't imagine that doing anything useful.

It's almost certainly an i370 port bug, but I haven't had any bright
ideas on how to fix that yet.  :-)

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> > As an alternative to the operand predicate, you might also add
> > an extra check to the insn condition.  For example, something
> > along the following lines should work:
> > 
> > (define_insn ""
> >   [(set (match_operand:SI 0 "register_operand" "=d")
> >         (mult:SI (match_operand:SI 1 "register_operand" "0")
> >                  (match_operand:SI 2 "const_int_operand" "K")))]
> >   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
> 
> My eyes lit up when I saw that!  However, it produced a compiler
> error when I tried it.  But undeterred, I tried this:
> 
> (define_insn ""
>   [(set (match_operand:SI 0 "register_operand" "=d")
>         (mult:SI (match_operand:SI 1 "register_operand" "0")
>                  (match_operand:SI 2 "immediate_operand" "K")))]
>   "(GET_CODE (operands[2]) == CONST_INT
>    && REG_P (operands[0])
>    && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"

Huh.  Instead of adding an explicit CONST_INT check, my approach
above used a const_int_operand predicate (instead of immediate_operand).
That should have had the exact same effect ...   I'm not sure why the
REG_P check on the other operand would be necessary at this point.

> And it worked (verified by self-compile)!  And I relaxed the 
> constraint on the "M" instruction as well.  Those old warnings 
> are apparently irrelevant now.  Thank you sir.  :-)

OK, that's good to know.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

>> > The combination of predicates and constraints on this insn is broken.
>> >
>> > Before reload, the predicate "immediate_operand" explicitly allows
>> > *any* SImode immediate value.  However, during reload, the "K"
>> > constraint accepts only a subset of values.
>> 
>> Is there a way to give a predicate that just says "look at the
>> constraint"?
> 
> Not that I'm aware of.

This below was what I was hoping for ...

>> It seems a bit overkill to add a new predicate
>> for this one instruction.
> 
> As an alternative to the operand predicate, you might also add
> an extra check to the insn condition.  For example, something
> along the following lines should work:
> 
> (define_insn ""
>   [(set (match_operand:SI 0 "register_operand" "=d")
>         (mult:SI (match_operand:SI 1 "register_operand" "0")
>                  (match_operand:SI 2 "const_int_operand" "K")))]
>   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"

My eyes lit up when I saw that!  However, it produced a compiler
error when I tried it.  But undeterred, I tried this:

(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
^I(mult:SI (match_operand:SI 1 "register_operand" "0")
^I^I (match_operand:SI 2 "immediate_operand" "K")))]
  "(GET_CODE (operands[2]) == CONST_INT
   && REG_P (operands[0])
   && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"
  "*
{
  check_label_emit ();
  mvs_check_page (0, 4, 0);
  return \"MH^I%0,%H2\";
}"
   [(set_attr "length" "4")]
)

And it worked (verified by self-compile)!  And I relaxed the 
constraint on the "M" instruction as well.  Those old warnings 
are apparently irrelevant now.  Thank you sir.  :-)

> My point was that the MH instruction on an instruction set
> architecture level *does not accept* an immediate operand,
> but only a memory operand:
> 
>   MH     R1,D2(X2,B2)     [RX]
> 
> (There is a MULTIPLY HALFWORD IMMEDIATE (MHI) instruction as well, 
> but I'm assuming you don't want to use it in the i370 port as that
> instruction was added later on.)

Oh, I understand now.

> So the usual way of using MH to multiply by an immediate value
> is to place the constant into memory, typically some form of
> literal pool.  But I see nothing in the i370 port that would
> actually do that; instead, you seem to simply output the immediate
> value itself into the assembler source.

Right, with an "=".

> If this works, it seems that the assembler will under the covers
> manage a literal pool.  I was simply wondering if this is indeed
> what you're relying on ...

Yes indeed.

And we go to a lot of effort to maintain the length of that literal
pool, so we know when we need to break out into a new page.

That's what this does:

>>   mvs_check_page (0, 4, 0);

Although, as usual, it's broken.  Needs to be (0, 4, 2) for the
4-byte instruction followed by the 2 bytes it will use from the
literal pool.

> (In the s390 port, the compiler will
> always manage literal pools completely on its own and does never
> rely on any assembler magic in that area.)

I see.  That explains one of the difficulties of trying to get s390
instruction definitions and use them on i370.  People keep asking
why I don't "just" use the s390 ones.  If only life were that
simple.  :-)

> Well, in this case someone has to push the constant into a literal pool.
> You can either do this at expand time by calling force_const_mem, or else
> you have to change the predicate to also accept immediates before reload
> (then reload will do the force_const_mem for you).  (Note that if you in
> fact do not manage a literal pool in the compiler today but rely on the
> assembler, as discussed above, this whole approach may be difficult.)

That's putting it mildly.  :-)

Anyway, with that out of the way, I'll take a look at the next one.
There's only one bug remaining that I know of, and 3 workarounds
that I would like to reverse out and fix properly.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> > The combination of predicates and constraints on this insn is broken.
> >
> > Before reload, the predicate "immediate_operand" explicitly allows
> > *any* SImode immediate value.  However, during reload, the "K"
> > constraint accepts only a subset of values.
> 
> Is there a way to give a predicate that just says "look at the
> constraint"?

Not that I'm aware of.

> It seems a bit overkill to add a new predicate
> for this one instruction.

As an alternative to the operand predicate, you might also add
an extra check to the insn condition.  For example, something
along the following lines should work:

 (define_insn ""
   [(set (match_operand:SI 0 "register_operand" "=d")
         (mult:SI (match_operand:SI 1 "register_operand" "0")
                  (match_operand:SI 2 "const_int_operand" "K")))]
   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"

> > As there is no other alternative,
> 
> No other alternative for this same pattern, right?  There was an
> alternative - the pattern that I explictly asked it to use, since
> I'd already done the K check in advance.

I was using "alternative" in the sense of multi-alternative
constraints within a single insn pattern, yes.  Reload will
never switch to use a different insn pattern, it will only
select one of the existing alternatives in the pattern.

> > and the insn supports neither memory nor register
> > operands, this is impossible for reload to fix up.
> 
> Hmmm.  I was wondering whether I could put a memory operand
> there, if that means it can fix it up regardless.  But that would
> give it the idea that it can put a fullword there, when a halfword
> operand is required, right?

Yes, the memory operand would have to be HImode in that case.

> > In addition, I don't quite understand how this pattern works in
> > the first place; MH requires a memory operand, but this pattern
> > seems to output an immediate value as operand.  Is there some
> > magic going on in your assembler?
> 
> %H2 is ...
> 
> ;; Special formats used for outputting 370 instructions.
> ;;
> ;;   %H -- Print a signed 16-bit constant.

Yes, it prints an immediate *constant*.

> > If you indeed want to output immediate values here, you should
> 
> As opposed to wanting what?  All I want is the MH instruction
> to be available for use, so that when someone writes x = x * 5,
> it doesn't have to organize a register pair.

My point was that the MH instruction on an instruction set
architecture level *does not accept* an immediate operand,
but only a memory operand:

   MH     R1,D2(X2,B2)     [RX]

(There is a MULTIPLY HALFWORD IMMEDIATE (MHI) instruction as well, 
but I'm assuming you don't want to use it in the i370 port as that
instruction was added later on.)

So the usual way of using MH to multiply by an immediate value
is to place the constant into memory, typically some form of
literal pool.  But I see nothing in the i370 port that would
actually do that; instead, you seem to simply output the immediate
value itself into the assembler source.

If this works, it seems that the assembler will under the covers
manage a literal pool.  I was simply wondering if this is indeed
what you're relying on ...   (In the s390 port, the compiler will
always manage literal pools completely on its own and does never
rely on any assembler magic in that area.)

> e.g. I managed to make this:
> 
> (define_insn ""
>  [(set (match_operand:SI 0 "register_operand" "=d")
>        (mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "g"))
>                 (match_operand:SI 1 "register_operand" "0")))]
>  ""
>  "*
> {
>   check_label_emit ();
>   mvs_check_page (0, 4, 0);
>   return \"MH^I%0,%2\";
> }"
>    [(set_attr "length" "4")]
> )
> 
> produce:
> 
> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>          cfgloopanal.c
> cfgloopanal.c: In function `average_num_loop_insns':
> cfgloopanal.c:1379: error: unrecognizable insn:
> (insn 68 67 71 7 (set (reg:SI 45)
>         (mult:SI (reg:SI 44 [ <variable>.frequency ])
>             (const_int 10000 [0x2710]))) -1 (insn_list 67 (nil))
>     (expr_list:REG_DEAD (reg:SI 44 [ <variable>.frequency ])
>         (nil)))

Well, in this case someone has to push the constant into a literal pool.
You can either do this at expand time by calling force_const_mem, or else
you have to change the predicate to also accept immediates before reload
(then reload will do the force_const_mem for you).  (Note that if you in
fact do not manage a literal pool in the compiler today but rely on the
assembler, as discussed above, this whole approach may be difficult.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

Hi Ulrich.

Good news is that I have now gotten GCC 3.4.6 to recompile
itself with full optimization on.  The compilation time on the
(emulated) mainframe is only 2.5 hours as only a single pass
is required.  GCC 3.4.6 requires 49 MB to recompile c-common!

I assume with GCC 3.4.6 it is doing global optimization or
something.  It was only 20 MB under 3.2.3.

Anyway, I'm still continuing the cleanup, but now have a strong
fallback position.  Basically I won't introduce any machine
definition change that causes the self-compile to fail.

>> ;(define_insn ""
>> ;  [(set (match_operand:SI 0 "register_operand" "=d")
>> ;       (mult:SI (match_operand:SI 1 "register_operand" "0")
>> ;                (match_operand:SI 2 "immediate_operand" "K")))]
>> ;  ""
>> ;  "*
>> ;{
>> ;  check_label_emit ();
>> ;  mvs_check_page (0, 4, 0);
>> ;  return \"MH  %0,%H2\";
>> ;}"
>> ;   [(set_attr "length" "4")]
>> ;)
>
> The combination of predicates and constraints on this insn is broken.
>
> Before reload, the predicate "immediate_operand" explicitly allows
> *any* SImode immediate value.  However, during reload, the "K"
> constraint accepts only a subset of values.

Is there a way to give a predicate that just says "look at the
constraint"?  It seems a bit overkill to add a new predicate
for this one instruction.

> As there is no other alternative,

No other alternative for this same pattern, right?  There was an
alternative - the pattern that I explictly asked it to use, since
I'd already done the K check in advance.

> and the insn supports neither memory nor register
> operands, this is impossible for reload to fix up.

Hmmm.  I was wondering whether I could put a memory operand
there, if that means it can fix it up regardless.  But that would
give it the idea that it can put a fullword there, when a halfword
operand is required, right?

> In addition, I don't quite understand how this pattern works in
> the first place; MH requires a memory operand, but this pattern
> seems to output an immediate value as operand.  Is there some
> magic going on in your assembler?

%H2 is ...

;; Special formats used for outputting 370 instructions.
;;
;;   %H -- Print a signed 16-bit constant.

in the i370.md documentation which can be seen here:

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i370/i370.md?revision=71850&view=markup&pathrev=77215

(there's not a lot of technical changes since then, mainly
because no-one knew how to make them).

> If you indeed want to output immediate values here, you should

As opposed to wanting what?  All I want is the MH instruction
to be available for use, so that when someone writes x = x * 5,
it doesn't have to organize a register pair.

> probably define a new *predicate* that constrains the set of
> allowed values even before reload.

Ok, that should be straightforward if that's the best solution.

> In the s390 port, we're instead modelling the MH instruction
> with a memory operand (this still allows the generic parts of
> GCC to push immediate operands into memory, if they are in
> range for an HImode operand):
>
> (define_insn "*mulsi3_sign"
>  [(set (match_operand:SI 0 "register_operand" "=d")
>        (mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "R"))
>                 (match_operand:SI 1 "register_operand" "0")))]
>  ""
>  "mh\t%0,%2"
>  [(set_attr "op_type"  "RX")
>   (set_attr "type"     "imul")])

I tried a lot of variations to try to get this to fit into the i370
scheme, but didn't have any luck.

e.g. I managed to make this:

(define_insn ""
 [(set (match_operand:SI 0 "register_operand" "=d")
       (mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "g"))
                (match_operand:SI 1 "register_operand" "0")))]
 ""
 "*
{
  check_label_emit ();
  mvs_check_page (0, 4, 0);
  return \"MH^I%0,%2\";
}"
   [(set_attr "length" "4")]
)

produce:

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include
         cfgloopanal.c
cfgloopanal.c: In function `average_num_loop_insns':
cfgloopanal.c:1379: error: unrecognizable insn:
(insn 68 67 71 7 (set (reg:SI 45)
        (mult:SI (reg:SI 44 [ <variable>.frequency ])
            (const_int 10000 [0x2710]))) -1 (insn_list 67 (nil))
    (expr_list:REG_DEAD (reg:SI 44 [ <variable>.frequency ])
        (nil)))

> This also seems broken.  A MULT:DI must have two DImode operands,
> it cannot have one DImode and one SImode operand.  Also, it is in
> fact incorrect that it takes the full DImode first operand; rather,
> it only uses the low 32-bit of its first operand as input.

Ok.

> In the s390 port we're modelling the real behavior of the instruction
> using two explicit SIGN_EXTEND codes:
>
> (define_insn "mulsidi3"
>  [(set (match_operand:DI 0 "register_operand" "=d,d")
>        (mult:DI (sign_extend:DI
>                   (match_operand:SI 1 "register_operand" "%0,0"))
>                 (sign_extend:DI
>                   (match_operand:SI 2 "nonimmediate_operand" "d,R"))))]

Ok.  That certainly looks better.

> Well, the point of optimization is that the RTXes do not stay the
> way they were originally expanded ...   The optimizers will attempt
> to perform various generic optimization on the code, and if the
> back-end claims to support a pattern that implements any of those
> optimized forms, it will get used.  In this case, even though you
> expanded a DImode multiply, common code may notice that it can
> be optimized to a SImode multiply instead.
>
> Generally speaking, your RTX patterns *must* be fully correct and
> represent the actual behavior of the machine in all cases.  If there
> are corner cases formally allowed by the RTX pattern, but the
> behavior of the machine differs, this may cause breakage.  Even if
> your expanders avoid those corner cases when using your patterns,
> this will not be true for the optimizers.

Ok.  It seems the proper way to go, but given that I don't know
how to integrate that into the existing code, it's probably better
for me to go with the new predicate, which I can very likely get
to work.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> Hi Ulrich.  Thanks for the reply.  I didn't use gcc_assert because I
> didn't see it defined anywhere, but the rest of the fix worked fine.

Ah, I see this macro was only added in 4.x.  In 3.x you should just
use abort () directly, like so:

  if (GET_CODE (dest) != LABEL_REF)
    abort ();

> (*) I had to disable the MH (multiply halfword) instruction in order
> to get it to go through unfortunately.  See below (+).
 
> (+) Can you spot anything wrong with this?

> ;(define_insn ""
> ;  [(set (match_operand:SI 0 "register_operand" "=d")
> ;       (mult:SI (match_operand:SI 1 "register_operand" "0")
> ;                (match_operand:SI 2 "immediate_operand" "K")))]
> ;  ""
> ;  "*
> ;{
> ;  check_label_emit ();
> ;  mvs_check_page (0, 4, 0);
> ;  return \"MH  %0,%H2\";
> ;}"
> ;   [(set_attr "length" "4")]
> ;)

The combination of predicates and constraints on this insn is broken.

Before reload, the predicate "immediate_operand" explicitly allows
*any* SImode immediate value.  However, during reload, the "K"
constraint accepts only a subset of values.  As there is no other
alternative, and the insn supports neither memory nor register
operands, this is impossible for reload to fix up.

In addition, I don't quite understand how this pattern works in
the first place; MH requires a memory operand, but this pattern
seems to output an immediate value as operand.  Is there some
magic going on in your assembler?

If you indeed want to output immediate values here, you should
probably define a new *predicate* that constrains the set of
allowed values even before reload.

In the s390 port, we're instead modelling the MH instruction
with a memory operand (this still allows the generic parts of
GCC to push immediate operands into memory, if they are in
range for an HImode operand):

(define_insn "*mulsi3_sign"
  [(set (match_operand:SI 0 "register_operand" "=d")
        (mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "R"))
                 (match_operand:SI 1 "register_operand" "0")))]
  ""
  "mh\t%0,%2"
  [(set_attr "op_type"  "RX")
   (set_attr "type"     "imul")])

> ; See mulsi3 comment above as to why this is constrained to
> ; "di" rather than "g"
> (define_insn ""
>   [(set (match_operand:DI 0 "register_operand" "=d")
>         (mult:DI (match_operand:DI 1 "general_operand" "0")
>                  (match_operand:SI 2 "general_operand" "di")))]
>   ""
>   "*
> {
>   check_label_emit ();
>   if (REG_P (operands[2]))
>     {
>       mvs_check_page (0, 2, 0);
>       return \"MR       %0,%2\";
>     }
>   mvs_check_page (0, 4, 0);
>   return \"M    %0,%2\";
> }"
>    [(set_attr "length" "4")]
> )

This also seems broken.  A MULT:DI must have two DImode operands,
it cannot have one DImode and one SImode operand.  Also, it is in
fact incorrect that it takes the full DImode first operand; rather,
it only uses the low 32-bit of its first operand as input.

In the s390 port we're modelling the real behavior of the instruction
using two explicit SIGN_EXTEND codes:

(define_insn "mulsidi3"
  [(set (match_operand:DI 0 "register_operand" "=d,d")
        (mult:DI (sign_extend:DI
                   (match_operand:SI 1 "register_operand" "%0,0"))
                 (sign_extend:DI
                   (match_operand:SI 2 "nonimmediate_operand" "d,R"))))]
  "!TARGET_64BIT"
  "@
   mr\t%0,%2
   m\t%0,%2"
  [(set_attr "op_type"  "RR,RX")
   (set_attr "type"     "imul")])

> Regardless, when that code is NOT commented out, such that I get that
> error, it is surprising that it is passing through this code:
> 
>       emit_insn (gen_rtx_SET (VOIDmode, r,
>                           gen_rtx_MULT (DImode, r, operands[2])));
> 
> where it is clearly attempting to do a DImode multiply, and thus
> shouldn't be matching the MH, that I am getting the problem.

Well, the point of optimization is that the RTXes do not stay the
way they were originally expanded ...   The optimizers will attempt
to perform various generic optimization on the code, and if the
back-end claims to support a pattern that implements any of those
optimized forms, it will get used.  In this case, even though you
expanded a DImode multiply, common code may notice that it can
be optimized to a SImode multiply instead.

Generally speaking, your RTX patterns *must* be fully correct and
represent the actual behavior of the machine in all cases.  If there
are corner cases formally allowed by the RTX pattern, but the
behavior of the machine differs, this may cause breakage.  Even if
your expanders avoid those corner cases when using your patterns,
this will not be true for the optimizers.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> Therefore, the i370_branch_dest routine needs to handle
> those as well.  Probably something along the following lines:
>
>  if (GET_CODE (dest) == IF_THEN_ELSE)
>    {
>      if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
> dest = XEXP (dest, 1);
>      else
> dest = XEXP (dest, 2);
>    }
>
>  gcc_assert (GET_CODE (dest) == LABEL_REF);
>  dest = XEXP (dest, 0);

Hi Ulrich.  Thanks for the reply.  I didn't use gcc_assert because I
didn't see it defined anywhere, but the rest of the fix worked fine.

I have now reached the stage where I can (*) self-compile with
optimization on (**).  It takes 6 hours (***).  :-)

(*) I had to disable the MH (multiply halfword) instruction in order
to get it to go through unfortunately.  See below (+).

(**) Except that c-common is being compiled with it off, because of
a bug in the emulator I think, rather than GCC.

(***) It would be closer to 4 hours if I didn't have to do two passes on
the mainframe.  I can't do that though until I can verify the integrity
of the generated code.  And I can't do that until I can get a fully
optimized compile done, because otherwise the register selection changes
slightly on PC vs mainframe causing slight differences in the one
file being compiled without optimization, that prevents an automatic
compare.


(+) Can you spot anything wrong with this?

Here is the error I get:

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include
         cppexp.c
cppexp.c: In function `ZZZ_1148':
cppexp.c:980: error: unable to generate reloads for:
(insn 15 14 19 0 (set (reg:SI 4 4 [32])
        (mult:SI (reg:SI 4 4 [30])
            (const_int -858993459 [0xcccccccd]))) 52 {*i370.md:2585} 
(insn_list
12 (nil))
    (expr_list:REG_DEAD (reg:SI 4 4 [30])
        (nil)))
cppexp.c:980: internal compiler error: in find_reloads, at reload.c:3690
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gccmvs.sourceforge.net> for instructions.


I can bypass this error by commenting out the MH pattern, and
the code that would normally invoke it.  Note that I didn't write
that "XXX trouble" stuff, and I don't know if it is still relevant.

;
; mulsi3 instruction pattern(s).
;

(define_expand "mulsi3"
  [(set (match_operand:SI 0 "general_operand" "")
        (mult:SI (match_operand:SI 1 "general_operand" "")
                 (match_operand:SI 2 "general_operand" "")))]
  ""
  "
{
  /*if (GET_CODE (operands[1]) == CONST_INT
      && REG_P (operands[0])
      && CONST_OK_FOR_LETTER_P (INTVAL (operands[1]), 'K'))
    {
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_MULT (SImode, operands[2], operands[1])));
    }
  else if (GET_CODE (operands[2]) == CONST_INT
           && REG_P (operands[0])
           && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))
    {
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_MULT (SImode, operands[1], operands[2])));
    }
  else */
    {
      rtx r = gen_reg_rtx (DImode);

      /* XXX trouble.  Below we generate some rtx's that model what
       * is really supposed to happen with multiply on the 370/390
       * hardware, and that is all well & good.  However, during 
optimization
       * it can happen that the two operands are exchanged (after all,
       * multiplication is commutitive), in which case the doubleword
       * ends up in memory and everything is hosed.  The gen_reg_rtx
       * should have kept it in a reg ...  We hack around this
       * below, in the M/MR isntruction pattern, and constrain it to
       * \"di\" instead of \"g\".  But this still ends up with lots & lots 
of
       * movement between registers & memory and is an awful waste.
       * Dunno how to untwist it elegantly; but it seems to work for now.
       */
      if (GET_CODE (operands[1]) == CONST_INT)
      {
      emit_insn (gen_rtx_SET (VOIDmode,
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode)),
                                          operands[1]));
      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[2])));
      }
      else
      {
      emit_insn (gen_rtx_SET (VOIDmode,
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode)),
                                          operands[2]));
      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[1])));
      }
      emit_insn (gen_rtx_SET (VOIDmode, operands[0],
                          gen_rtx_SUBREG (SImode, r, GET_MODE_SIZE 
(SImode))));
    }
  DONE;
}")

;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=d")
;       (mult:SI (match_operand:SI 1 "register_operand" "0")
;                (match_operand:SI 2 "immediate_operand" "K")))]
;  ""
;  "*
;{
;  check_label_emit ();
;  mvs_check_page (0, 4, 0);
;  return \"MH  %0,%H2\";
;}"
;   [(set_attr "length" "4")]
;)

; See mulsi3 comment above as to why this is constrained to
; "di" rather than "g"
(define_insn ""
  [(set (match_operand:DI 0 "register_operand" "=d")
        (mult:DI (match_operand:DI 1 "general_operand" "0")
                 (match_operand:SI 2 "general_operand" "di")))]
  ""
  "*
{
  check_label_emit ();
  if (REG_P (operands[2]))
    {
      mvs_check_page (0, 2, 0);
      return \"MR       %0,%2\";
    }
  mvs_check_page (0, 4, 0);
  return \"M    %0,%2\";
}"
   [(set_attr "length" "4")]
)


Regardless, when that code is NOT commented out, such that I get that
error, it is surprising that it is passing through this code:

      emit_insn (gen_rtx_SET (VOIDmode, r,
                          gen_rtx_MULT (DImode, r, operands[2])));

where it is clearly attempting to do a DImode multiply, and thus
shouldn't be matching the MH, that I am getting the problem.

Although almost all of the GCC code can be compiled with
this in place.  It's only when I have that very large constant,
0xcccccccd, not sure where that's coming from, that I have
the problem.

Commenting out the MH pattern (and the code that tries to
call MH) makes it happily use the proper intended MR instruction,
and everything works so well that gcc 3.4.6 can self-compile
on an EBCDIC environment.  :-)

Any ideas?

Thanks.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> int
> i370_branch_dest (branch)
>      rtx branch;
> {
>   rtx dest = SET_SRC (PATTERN (branch));
>   int dest_uid;
>   int dest_addr;
> 
>   /* first, compute the estimated address of the branch target */
>   if (GET_CODE (dest) == IF_THEN_ELSE)
>     dest = XEXP (dest, 1);
>   dest = XEXP (dest, 0);

This is set up only to handle direct branches of the form

  (set (pc) (label_ref ...))

and indirect branches of the form

  (set (pc) (if_then_else (...) (label_ref ...) (pc)))

but *not* indirect branches of the form

  (set (pc) (if_then_else (...) (pc) (label_ref ...)))

This latter form is accepted by the "negated conditional
jump instructions in the i370.md file, like so:

(define_insn ""
  [(set (pc)
        (if_then_else (eq (cc0)
                          (const_int 0))
                      (pc)
                      (label_ref (match_operand 0 "" ""))))
;   (clobber (reg:SI 14))
   ]
  ""
  "*
{
  check_label_emit ();
  mvs_check_page (0, 4, 0);
  if (i370_short_branch(insn) || mvs_check_label (CODE_LABEL_NUMBER (operands[0])))
    {


Therefore, the i370_branch_dest routine needs to handle
those as well.  Probably something along the following lines:

  if (GET_CODE (dest) == IF_THEN_ELSE)
    {
      if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
	dest = XEXP (dest, 1);
      else
	dest = XEXP (dest, 2);
    }

  gcc_assert (GET_CODE (dest) == LABEL_REF);
  dest = XEXP (dest, 0);

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port

[Paul Edwards]

> 2. I am unable to do an optimized compile even as a cross-compile,
> I get an internal error in this function:
> 
> gcse.c:
> 
> static void
> compute_hash_table_work (struct hash_table *table)
> {
> ...
>  if (!current_bb) /* +++ why are we getting NULL here? */

It appears I have misdiagnosed this.  The code will handle NULL
already.  Taking that out though, exposes this internal error:

int
i370_branch_dest (branch)
     rtx branch;
{
  rtx dest = SET_SRC (PATTERN (branch));
  int dest_uid;
  int dest_addr;

  /* first, compute the estimated address of the branch target */
  if (GET_CODE (dest) == IF_THEN_ELSE)
    dest = XEXP (dest, 1);
  dest = XEXP (dest, 0);
  /* +++ why is this becoming NULL? */
  if (!dest)
  {
      printf("internal error in branch dest\n");
      exit (0);
  }

which is obviously specific to the i370 port.  This code works fine on
3.2.3 though, so any idea what 3.4.6 changed to stop this from
working?

Thanks.  Paul.




  dest_uid = INSN_UID (dest);
  dest_addr = INSN_ADDRESSES (dest_uid);

  /* next, record the address of this insn as the true addr of first ref */
  {
     label_node_t *lp;
     rtx label = JUMP_LABEL (branch);
     int labelno = CODE_LABEL_NUMBER (label);

     if (!label || CODE_LABEL != GET_CODE (label)) abort ();

     lp = mvs_get_label (labelno);
     if (-1 == lp -> first_ref_page) lp->first_ref_page = mvs_page_num;
     just_referenced_page = lp->label_page;
  }
  return dest_addr;
}

Re: i370 port

[Henrik Sorensen]

On Sunday 23 August 2009 04.27:11 Paul Edwards wrote:
>
> Jujitsu are pleased to announce the release of the
> following software:
>
> GCC 3.2.3 MVS 7.5 - GCC C compiler for z/OS, MVS/380, MVS/370.
> GCC 3.2.3 CMS 7.5 - GCC C compiler for z/VM, VM/380, VM/370.
> PDPCLIB 2.00 - C (C90-compliant) runtime library for MVS
> Hercules/380 3.06 v6.0 - Used to run MVS/380. It now does

Hi Paul

Congrats !!

good to see you are making progress, and also getting feedback on the 
gcc-list.
> BFN.  Paul.
Henrik

Re: i370 port

[Paul Edwards]

>> > How does this work?  ASM_FORMAT_PRIVATE_NAME is not supposed
>> > to completely ignore the NAME argument, the function may well
>> > be called with the same LABELNO but different NAME strings,
>> > and this must not result in conflicting symbols ...
>> 
>> I have compiled the entire GCC and not come up with any duplicate
>> static function names, so I think the number is always unique.
> 
> Hmm, I see that in the 3.2.x code base this is indeed true.
> However, in later compilers ASM_FORMAT_PRIVATE_NAME is used
> for other purposes by the middle-end, not just static function
> or variable names.  You definitely can get number collisions
> in later compilers ...

Well I've compiled and linked all of 3.4.6 without getting name
clashes either.

>> > At this point, you may refer to "current_function_decl" to
>> > retrieve information about the function currently being output.
>> > In particular, you can retrieve the original source-level name
>> > associated with the routine via DECL_NAME (current_function_decl).
>> 
>> Thanks a lot!  I couldn't use that directly, but this:
> 
> Why not?  

It was missing the IDENTIFIER_POINTER so getting a compile
error.

>  printf ("%s", IDENTIFIER_POINTER (DECL_NAME (current_function_decl)));
> 
> should work fine ...

Yes, I've adopted that, thanks.

Anyway, I've finally packaged all those changes discussed on the
list, and also creditted you in the documentation for your assistance
in polishing the product off.  Details in announcement below.

BFN.  Paul.






Jujitsu are pleased to announce the release of the
following software:

GCC 3.2.3 MVS 7.5 - GCC C compiler for z/OS, MVS/380, MVS/370.
Delivered in xmit format.

GCC 3.2.3 CMS 7.5 - GCC C compiler for z/VM, VM/380, VM/370.
Delivered in vmarc format.

PDPCLIB 2.00 - C (C90-compliant) runtime library for MVS 
(all flavours), CMS (all flavours), Windows 32, MSDOS, 
OS/2, Linux (new with this release), PDOS. Provided in
source form only, but also delivered as part of GCCMVS
and GCCCMS.

Hercules/380 3.06 v6.0 - Used to run MVS/380. It now does
S/380 even if you specify S/370, so that Hercgui will
work. Now has native support for ftp-rdw files (ie files
that have been transferred from z/OS using ftp with
the RDW option), so that you can quickly get your files
restored to a V dataset. Windows executables provided.
Unix users need to compile from source.

You can find the products at:

http://gccmvs.sourceforge.net
http://pdos.sourceforge.net
http://mvs380.sourceforge.net

(respectively).

Initial documentation can be found in gccmvs.txt,
pdpclib.txt and README.S380 respectively.

Any comments/questions please post over at:

http://tech.groups.yahoo.com/group/hercules-os380

where our complaint department is in operation 24
hours a day, even during Ramadan - may Allah have
mercy on our souls.

BFN.  Paul.