--- In
H390-MVS@..., "ivan_warhead" <ivan@...> wrote:
>
> (in message 3425 dated 2004-01-06 for anyone wondering)
>
> > Current status: Working GCCMVS on MVS 3.8j for some test
> programs.
> > Not yet compiled itself. A floating point has appeared and needs
> to
> > be nailed down. :-)
> >
> Is this, by any chance, an issue with an 'impossible register
> reload' while compiling libgcc's _udivdi3 ?
No, we weren't using libgcc. However, there were plenty
of such errors you alluded to in the machine definition.
> My own experience on adapting GCC 3.4 (I am using the 12/24/2003
> Snapshot) is that a few tweaks (about 10) are needed until proper
> code is generated.
I have apparently finally caught up to you. I am
working on 3.4.6 now. I have GCCMVS self-compiling
*unoptimized* on that environment. I experienced
several problems when I switched on optimization,
and one of them turned out to be with movstrictqi.
So I did a google search on movstrictqi to find
out what it actually was.
And guess what came up?
Greetings from cyberspace ...
> Here are a few :
>
> 1) movstrictqi in i370.md generates a lot of problems (especially
> with -O2) - if movstrictqi is not commented out, the optimizer
> generates garbage (for example, in a switch/case statement, some
> branches are never taken)
Didn't think of simply commenting it out. I have done
so now, and should have a result soon.
...
Yep, that did the trick, thanks! That moved me on to
the next problem ... movstricthi!
movstrict means that it doesn't clobber the other bytes
in the register. However, for some reason, the compiler
thinks that if you don't clobber the bits, you can
avoid that entire COMPARISON thing! ie we have ICMs but
not CLR.
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
Seems stupid to use ICM in this circumstances anyway.
What's wrong with the LAs that were working so well
before?
It'd be nice to think there's a better solution than
simply commenting it out though!
> 2) movdi is missing a 'm' constraint for 2nd operand (that's why
> _udivdi3 won't compile)
There are two movdi's. I assume the first one is in
use.
[(set (match_operand:DI 0 "r_or_s_operand" "=dS,m")
(match_operand:DI 1 "r_or_s_operand" "diS*fF,d*fF"))]
[(set (match_operand:DI 0 "general_operand" "=d,dm")
(match_operand:DI 1 "r_or_s_operand" "diSF,*fd"))]
It took a huge effort to get these things to work
properly in 3.2.3. There was virtually no change in
the machine definition from 3.2.3 to 3.4.6 (I now
know) so we probably dealt with the same thing.
Here is what it has now morphed into. This means changes
from Dave Pitts, Linas, and Dave Wade and myself.
[(set (match_operand:DI 0 "nonimmediate_operand" "=d,m,S")
(match_operand:DI 1 "general_operand" "g,d,SF"))]
There is now a path from a source m (memory address) -
actually I used g (general) to a desination register
(d), which makes the compiler happy.
> 3) i370.c has some issues when scanning for jump signedness because
> if-then-else insns may be reverted (leading to various ICEs)
Are you talking about this "== PC" check I needed to
add after a bit of experimentation?
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);
if (GET_CODE (dest) == PC)
{
dest_uid = INSN_UID (dest);
dest_addr = INSN_ADDRESSES (dest_uid);
return dest_addr;
}
Is that the proper fix? I didn't really know what
I was doing, so guessed and the guess seemed to work
in so much as I can now optimize some programs, with
some success. I normally reserve judgement until
things self-compile again.
> 4) There is a problem (only occurs in i370.md but it may be a
> generic problem) where a unconditional jump_insn followed by a
> code_label insn gives an ICE because it generates the code_label
> edge as a fallthrough edge. This can be bypassed by recoding the
> i370.md logic to never get that case (occurs in the umulsi & udivsi
> insns)
I couldn't find the umulsi. I know that multiply is
complicated. I also know that under 3.4.6, I am
having this problem:
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]))) 54 {*i370.md:2564}
(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
which didn't happen under 3.2.3. I can comment out
the MH instruction to make it go away, but that's an
unpleasant thing to do, and triggered off some
tougher problems to solve (work in progress).
> Now.. there is also ONE big problem :
>
> 3.4 eliminated EBCDIC specifics and went to a more direct and
> generic cross charset scheme. A specific precompiler flag (-fexec-
> charset) can be used to indicate the execution charset. However,
> this is completelly incompatible with
> a) The way i370.c generates string constants (that is specific to
> i370.c) - I had to patch my copy so as to generate DC X'...' instead
> of DC C'...'
> b) With any strings that are interpreted by the compiler (ex:
> extern "C" - or __asm__("..."..) (This is an open PR in gcc :
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13258) - I patched the C
> parser (cparse.in) to 'untranslate' language specific strings..
>
> Without these changes (and without using the -fexec-charset flag),
> any single char constant (ex : 'c') are converted to ascii integers
> in the resulting assembler file. (ex : the statement {char c='a';}
> is converted to LA 1,41)
This is an interesting topic. I heard a similar
complaint from Dave Pitts about all the required
code being ripped out.
On the other hand, I had seen glowing references
to the GCC 3.4.6 changes from David Bond, from
Tachyonsoft, when I was reading stuff about lib390.
I think he even did a SHARE presentation about it.
I contacted both Davids to try to sort out the
discrepancy, but simply got a restatement of what
they had each said.
When I actually came to do it myself then, I didn't
know what to expect. I had been given somewhat
working 3.4.6 code from Dave Pitts, so it had been
done his way. However, I had an ASCII to EBCDIC
problem and needed to do something about it.
I could see that the GCC people had gone to the
effort of putting this in, and it must have done
something. So I basically took out all Dave Pitts
changes related to character set conversion and
tried to find what the "default" version did wrong.
Of course I didn't have the various libconvs available,
so I simply dummied that up to use the normal
translation tables from Dave Pitts (3.2.3) which I
had previously (3.2.3) modified for another problem,
and it seemed to work.
There was some minor stuff you mentioned in the
i370 directory, where some translations had to
not be done.
There was also the "asm" problem you mentioned
above. That's there in 3.2.3 too. However, it's
not actually a problem once you get up onto the
host. And the compiler itself doesn't use asm
to do anything relevant.
Obviously I couldn't be sure of this until I
actually saw a self-compile go through, which
only happened a couple of days ago.
And I can't be totally totally sure until I see
an optimized self-compile go through, although,
that's not THAT important either, since if there
are still some ASCII/EBCDIC-related traps that
only occur when optimization is on, it doesn't
matter either - I can delay optimization until
when I'm on the host.
> Note :
>
> I have asked the GCC folks if they could reconsider obsoleting
> target i370-ibm-mvs..
And who would have guessed that one of the most
important computer systems in the world turned
out to be a boring target? People have been trying
to get this to work for more than 20 years!!! No
exaggeration.
> ReNote :
>
> I have a functional compiler (not fully tested though) now for
> VM/370 with a minimalistic C library.. At least I can code a few
> utilities..
Would you be able to give me this, plus the exact base
you used, so that I can see what you changed? I know
how much blood is let for each single character
(literally, like that "m" you mentioned above) that is
changed in GCC and I'd like to not miss any that have
already been done, like that strict above.
BTW, you seem to know what you are talking about. Now
that we're approaching a consolidated final version,
and before any attempt is made to upgrade to GCC 4,
would you be able to appraise the status of 3.4.6
(when I've finished the current effort) and provide any recommedations?
I recently asked for some hooks on the GCC mailing
list, but maybe I'm asking for the wrong thing?
Thanks. Paul.
