From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Fri, 5 Jan 96 20:02:18 PST
Subject: Re: Row-major interpretation
Message-Id: <CMM.0.90.4.820900938.cwilson@Xenon.Stanford.EDU>
> The in_array instruction interprets a multi-dimensional array as being
> stored in row-major order (Suif Library Manual, page 40, last paragraph).
> This interpretation clashes with the statement at the beginning of Section
> 4.8 ("Because many SUIF passes focus on analyzing and optimizing FORTRAN
> code, a high-level representation of array references is crucial") because
> FORTRAN interprets a multi-dimensional array as being stored in
> column-major order.
There's no clash here. Section 4.8 says that SUIF uses a ``high
level'' representation for arrays so that there is a direct mapping
between Fortran and SUIF array references. It doesn't mean that SUIF
can't be column-major and Fortran row-major. It just means you
reverse the order of the indices in an array reference when switching
between Fortran and SUIF. It's still an isomorphism. The order of
the indices in the array reference is just a syntactic detail.
> The actual definition of ordering, which appears in ANSI X3.9-1978, Section
> 5.4.3, is stated in terms of the "subscript value" concept. This concept
> essentially reduces all arrays to one-dimensional arrays by providing the
> computation of an index from a set of subscripts. The subscript value is
> used to define ordering of array elements in COMMON and the correspondence
> created by EQUIVALENCEs.
>
> According to Section 15.9.3.3 of ANSI X3.9-1978, "The number and size of
> dimensions in an actual argument array declarator may be different from
> the number and size of the dimensions in an associated dummy argument
> array declarator. ... each actual argument array element becomes
> associated with the dummy argument array element that has the same
> subscript value as the actual argument array element."
>
> The assumption of row-major order by in_array therefore implies that this
> instruction can only be used to reference multi-dimensional arrays that do
> not participate in EQUIVALENCE relations, do not appear in COMMON, and are
> not passed between routines. In all other cases, the arrays must be
> converted to one-dimensional arrays and subscript calculations must be
> made explicit. The in_array instruction can still be used to reference
> the one-dimensional array, but most of its power is lost.
This argument just proves that if we didn't reverse the order or the
indices in translating from row-major to column-major we would be
incorrect. But we do reverse the order of the indices in array
reference instructions, so there is no problem.
> I assume that in_array is specified as assuming row-major order because
> that is the storage mechanism used in C and FORTRAN programs are presented
> to Suif by first translating them to C. In order to meet your goal of
> being able to analyze and optimize FORTRAN, however, I think you need to
> allow the user to choose the storage layout for arrays by providing a flag
> on the in_array instruction.
As I said, the ordering of indices in an array reference is just a
syntactic detail. You choose the storage layout and then you just
need to know whether the language in question is ``row-major'' or
``column-major'' to know how to write that information in the given
language. You can express any array reference from a column-major or
row-major language in SUIF.
--Chris
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Fri, 5 Jan 96 19:37:44 PST
Subject: Re: error in basesuif-1.1.0/src/basesuif/suif/instruction.cc
Message-Id: <CMM.0.90.4.820899464.cwilson@Xenon.Stanford.EDU>
> In in_gen::set_num_srcs(), the following code exists:
>
> void
> in_gen::set_num_srcs (unsigned n)
> {
> if (n <= ns) {
> ns = n;
> return;
> }
>
> operand *new_srcs = new operand[n];
>
> /* copy the old array (as much as possible) */
> unsigned i;
> for (i = 0; (i < ns) && (i < n); i++) {
> new_srcs[i] = srcs[i];
> }
>
> /* initialize any new source operands */
> for (unsigned j = ns; j < n; j++) {
> new_srcs[i] = operand();
> }
>
> ns = n;
> delete[] srcs;
> srcs = new_srcs;
> }
>
> The initialization loop (the 2nd for loop) is incorrect since the
> for-loop variable and the array index don't match. The following
> will work:
>
> void
> in_gen::set_num_srcs (unsigned n)
> {
> if (n <= ns) {
> ns = n;
> return;
> }
>
> operand *new_srcs = new operand[n];
>
> /* copy the old array (as much as possible) */
> unsigned i;
> for (i = 0; (i < ns) && (i < n); i++) {
> new_srcs[i] = srcs[i];
> }
>
> /* initialize any new source operands */
> for (; i < n; i++) {
> new_srcs[i] = operand();
> }
>
> ns = n;
> delete[] srcs;
> srcs = new_srcs;
> }
Thanks for the bug report. This will be fixed in the next release.
--Chris
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Fri, 5 Jan 96 19:48:25 PST
Subject: Re: intializing externs.
Message-Id: <CMM.0.90.4.820900105.cwilson@Xenon.Stanford.EDU>
> Hi.
>
> I'm doing a PPC backend to SUIF for my undergraduate thesis, under
> the supervision of Prof. Todd Mowry. If an external variable is intialized,
> snoot seems to die with the following:
>
> **** Program: /tcm/a/a0/suif/SPARC/bin/snoot
> **** Assertion failure in file "gen.cc" at line 523
> **** False expression: (s->scope == GLOBAL && s->sclass != EXTERN) || (s->scope)
> /tcm/a/a0/suif/SPARC/bin/snoot -Tsparc /tmp/scc12373_0.i /tmp/scc12373_1.snt
> FAILED (wait code 0x6)
>
>
> Example code:
> ------------
> extern int foo = 4;
>
> main()
> {
> }
>
>
> This is not an immediate problem, except that AIX seems to have some
> very stringent rules when it comes to how its assembler treats the data
> region. Specifically, unlike the MIPS/SPARC assemblers, everything has to be
> explicitly declared. I ran some tests with both gcc and AIX's cc, and both
> of them seem to turn the above foo into a normal, global variable.
>
>
> Is this is a known problem? If so, is there a patch to fix this?
>
>
> Regards,
> Damien.
No, this is not a know problem, nor can I repeat it. I took the
example code you gave and ran it through scc and there was no problem
in snoot or any other pass. snoot runs on many large programs with
lots of initialization data for globals without problem.
So this seems to be specific to your version of snoot. What version
is it? You can run ``snoot -version'' to get the version information.
The fact that the ``-Tsparc'' option works and the directory of the
binary is suif/SPARC (using old naming conventions) tends to indicate
you are not using the latest version of snoot. If you are not using
basesuif 1.1.0 I would recommend that you upgrade.
--Chris
From: Chris Wilson <cwilson@CS.Stanford.EDU>
Date: Fri, 5 Jan 96 19:21:46 PST
Subject: Re: Installation of Suif under HPUX
Message-Id: <CMM.0.90.4.820898506.cwilson@Xenon.Stanford.EDU>
> I have just completed a "make install" of basesuif-1.1.0 on an HP machine
> using gcc/g++ 2.6.3. All components except scc reported OK. The log for
> the failed component indicated that RLIMIT_STACK was undeclared. This is
> correct, since HP-UX does not implement a stack limit. I commented out the
> section of code containing the resource reset, and tried to make again,
> with the following result:
>
> make[1]: *** [show-install] Error 2
It's hard to know from that message what went wrong. You'll need to
look in the install.log file for whatever was being made at the time.
> I then tried "make install-noisy", which seemed to be making everything all
> over again. I killed that, and then tried "make install" again. It's not
> clear what's happening at the moment, since the machine is grinding away
> and not saying anything. I assume it's going through everything again.
>
> That seems rather unfriendly behavior on the part of a Makefile...
Because the SUIF system takes up so much disk space, the top level
Makefile's installation targets have special rules to do a ``make
clean'' in each subdirectory after installing it. That way you don't
have all those extra object files and executables using up space in
the build directory. This has the disadvantage that trying to do
``make install'' again will rebuild everything, but it isn't expected
that ``make install'' will be run more than once at the top level
unless everything needs to be rebuilt. If particular passes fail, you
can cd to the build directory for that pass and run ``make install''
there.
There is a reason the ``install'' target doesn't print anything until
it is finished. This target prints out a concise summary of the
successes or failures of the whole build. But an unfortunate
``feature'' of gmake is that it prints out a message every time a
``cd'' is done in a make. That was cluttering up the output badly.
There's no way to get gmake to turn off that behavior without making
it completely silent, which leaves the log files without all the
information we want recorded there. So the main tty output of the
``install'' target is piped through ``grep -v'' to kill the directory
changing messages. But on many systems grep blocks its input and
doesn't process it until it has a number of lines. That means that
for just a few lines, as in the output of the ``install'' target, none
of the output appears until all the input is finished, so until the
gmake is done with everything, nothing is printed. There's no
portable way to turn off this buffering.
This is not desirable behavior for our Makefile system, but there
doesn't seem to be an easy fix right now.
--Chris
From: William Waite <waite@scotty.cs.colorado.edu>
Date: Fri, 5 Jan 1996 13:27:59 -0700 (MST)
Subject: Row-major interpretation
Message-Id: <199601052027.NAA22821@scotty.cs.colorado.edu>
The in_array instruction interprets a multi-dimensional array as being
stored in row-major order (Suif Library Manual, page 40, last paragraph).
This interpretation clashes with the statement at the beginning of Section
4.8 ("Because many SUIF passes focus on analyzing and optimizing FORTRAN
code, a high-level representation of array references is crucial") because
FORTRAN interprets a multi-dimensional array as being stored in
column-major order.
The actual definition of ordering, which appears in ANSI X3.9-1978, Section
5.4.3, is stated in terms of the "subscript value" concept. This concept
essentially reduces all arrays to one-dimensional arrays by providing the
computation of an index from a set of subscripts. The subscript value is
used to define ordering of array elements in COMMON and the correspondence
created by EQUIVALENCEs.
According to Section 15.9.3.3 of ANSI X3.9-1978, "The number and size of
dimensions in an actual argument array declarator may be different from
the number and size of the dimensions in an associated dummy argument
array declarator. ... each actual argument array element becomes
associated with the dummy argument array element that has the same
subscript value as the actual argument array element."
The assumption of row-major order by in_array therefore implies that this
instruction can only be used to reference multi-dimensional arrays that do
not participate in EQUIVALENCE relations, do not appear in COMMON, and are
not passed between routines. In all other cases, the arrays must be
converted to one-dimensional arrays and subscript calculations must be
made explicit. The in_array instruction can still be used to reference
the one-dimensional array, but most of its power is lost.
I assume that in_array is specified as assuming row-major order because
that is the storage mechanism used in C and FORTRAN programs are presented
to Suif by first translating them to C. In order to meet your goal of
being able to analyze and optimize FORTRAN, however, I think you need to
allow the user to choose the storage layout for arrays by providing a flag
on the in_array instruction.
From: Damien Bonaventure <bonaven@eecg.toronto.edu>
Date: Fri, 5 Jan 1996 15:18:32 -0500
Subject: intializing externs.
Message-Id: <96Jan5.151833est.84(4)@picton.eecg.toronto.edu>
Hi.
I'm doing a PPC backend to SUIF for my undergraduate thesis, under
the supervision of Prof. Todd Mowry. If an external variable is intialized,
snoot seems to die with the following:
**** Program: /tcm/a/a0/suif/SPARC/bin/snoot
**** Assertion failure in file "gen.cc" at line 523
**** False expression: (s->scope == GLOBAL && s->sclass != EXTERN) || (s->scope)
/tcm/a/a0/suif/SPARC/bin/snoot -Tsparc /tmp/scc12373_0.i /tmp/scc12373_1.snt
FAILED (wait code 0x6)
Example code:
------------
extern int foo = 4;
main()
{
}
This is not an immediate problem, except that AIX seems to have some
very stringent rules when it comes to how its assembler treats the data
region. Specifically, unlike the MIPS/SPARC assemblers, everything has to be
explicitly declared. I ran some tests with both gcc and AIX's cc, and both
of them seem to turn the above foo into a normal, global variable.
Is this is a known problem? If so, is there a patch to fix this?
Regards,
Damien.