Re: i370 port

["Paul Edwards" <mutazilah@gmail.com>]

>> 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.