Re: [kaffe] mipsel/jit3 regression test results
Mikolaj Habryn wrote: On Tue, 2004-10-12 at 11:11, Timothy Stack wrote: To run it manually, you need to do something like the following in sh/bash: [..snip..] Magic, thanks! Results are: Bombed with Illegal Instruction: ControlFlowMethods, ObjectFields, PrimitiveArrays, StaticFields, StaticMethodCall, TypeConversion Passed: ConstMathMethods, ConstMethods, ParameterizedBitwiseMethods, ParameterizedLogicalMethods Aborted: ParameterizedMathMethods, ParameterizedMethods ...and I got bored waiting for MethodOptimizations to complete. That was without libffi. With libffi, the differences were: ConstMethods failed instead of passed. ParameterizedMethods failed instead of aborted. StaticMethodCall crashed the box :) Woops ;( Looks like static method calls are broken in general on mips with jit. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Notice the difference? The kaffe.def calls do the pushargs before the begin_func_sync and the icode.c calls do the pushargs after the begin_func_sync. Arghh!! Now, if only I knw what begin _func_sync really meant, I'd know whether that was really a problem! ;o) I could believe that the hack below may have helped some bug that PPC was seeing, and it might help MIPS as well, but if rreg_ideal_int() can be fatal, I would think that rreg_int() could be as well. Yeah, I might've just gotten lucky somehow... If the register already associated to the requesting slot is global, or if its type is the same as that requested (for read use) or its type is the same as requested and its reference count is only one (for write use), you'd avoid going to the allocator on a non-ideal rreg_mumble(). I suspect that covers more than 50% of the dynamic instances of GPR allocation. But on architures with distinct FPU registers (and that's most architectures these days), you would lose a lot more often on requests for floating registers. It's easy for me to say this as I sit here looking at sources on a Windows box with neither the means nor the opportunity to roll up my sleeves and do it myself, but I think that, rather than avoid the use of the rreg_ideal_mumble()'s, we need to fix the underlying problem, because it can happen anyway. And, actually, looking at the slotRegister() code (which is what all the rreg_mumble_mumble() macros expand to) it strikes me that I must have observed another bug when I was tracing the TestNative regression test failures. As I mentioned earlier, when the function call prologue was being generated and the arguments that wouldn't fit into the designated argument registers were being pushed onto the stack, each push invoked rreg_mumble(), and each time it returned a new register number, looping through the full set of usable registers until it clobbered the designated argument registers. Given what I observed above about slotRegister(), I don't understand why it is that we never seemed to be able to re-use the register binding to a slot. Whether by fixing some underlying machinery, or by judicious use of a fixed rreg_ideal_mumble(), we really ought to ensure that the same temporary registers are used through the whole argument push sequence. It should be good for a measurable performance increase. Regards, Kevin K. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Kevin The code generation in jit3-mips.def is going to generate all Kevin sorts of broken code if you allow those values to go above 31, Kevin I think. There is no masking of the shifted values as the Kevin instruction words are being created. I masked all the registers when generating instructions, and with the float registers renumbered all of the test/internal tests pass. Kaffe itself won't yet load, however. Did you also flag all the MIPS argument registers as Reserved? As we've all been saying, that's a work-around for a bug that is elsewhere, but it's a simple and effective work-around. Regards, and regrets to not be able to do this myself, Kevin K. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin == Kevin D Kissell [EMAIL PROTECTED] writes: Kevin The code generation in jit3-mips.def is going to generate all Kevin sorts of broken code if you allow those values to go above 31, Kevin I think. There is no masking of the shifted values as the Kevin instruction words are being created. I masked all the registers when generating instructions, and with the float registers renumbered all of the test/internal tests pass. Kaffe itself won't yet load, however. Kevin Did you also flag all the MIPS argument registers as Reserved? Kevin As we've all been saying, that's a work-around for a bug that Kevin is elsewhere, but it's a simple and effective work-around. Yes, the problem now stems from floating-point comparisons not working, which causes the Hashtable constructor to reject the loadFactor argument. I *think* this stems from renumbering the registers, which is looking to be more and more bogus. So fixing the register allocation is the thing to do, not kludging around it. But that's for next week. Kevin Regards, and regrets to not be able to do this myself, You've been more than helpful already; thanks. - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD4DBQFASkexgAuWMgRGsWsRAtswAJY0wgqvShax3HqhhSJO+LU/o4TXAKCNvDT3 4sNFR9ldW+R0g3TGgoc2aA== =39OZ -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
On Mar 5, 2004, at 4:24 PM, Casey Marshall wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin == Kevin D Kissell [EMAIL PROTECTED] writes: * If I renumber the float registers from 32 to 63, the spill problem doesn't happen, but I get a bus error when the `call' instruction is reached. This happens because the constant pool code tries to restore register gp from fp, and it looks like fp gets clobbered before this can happen. Kevin The code generation in jit3-mips.def is going to generate all Kevin sorts of broken code if you allow those values to go above 31, Kevin I think. There is no masking of the shifted values as the Kevin instruction words are being created. I masked all the registers when generating instructions, and with the float registers renumbered all of the test/internal tests pass. Hzzaa! Kaffe itself won't yet load, however. Well, its progress... This solution is obviously a hack; I don't think so, it should always be pretty easy for the backend to map the regno value to whatever needs to be put in the instruction. the correct fix is probobly to fix register.c to not assume that regno is an index into reginfo. I'm hesitant to mess with the register allocator too much, especially since it might break the other backends... Unrelated question to the peanut gallery: currently the stack trace I get when Kaffe is loading (an Internal error: caught an unexpected exception.) goes all the way back to java.lang.VMThrowable.fillInStackTrace(VMThrowable.java:native). Is this just a symptom of an exception being thrown early, or is this yet another problem with the MIPS backend? Most likely its normal, send the whole print out if you're really concerned. Casey Marshall || [EMAIL PROTECTED] tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timothy == Timothy Stack [EMAIL PROTECTED] writes: Timothy On Mar 5, 2004, at 4:24 PM, Casey Marshall wrote: This solution is obviously a hack; Timothy I don't think so, it should always be pretty easy for the Timothy backend to map the regno value to whatever needs to be put in Timothy the instruction. Since the machine code emitter believes that these numbers can be written into instructions as-is, I doubt that they should be changed. (That is, of course, unless it can no longer be assumed that regno is a valid part of an instruction) the correct fix is probobly to fix register.c to not assume that regno is an index into reginfo. Timothy I'm hesitant to mess with the register allocator too much, Timothy especially since it might break the other backends... I think it should be easy (FLW) to rework the register allocation without damaging the way register-sparse machines work by assuring that the behavior visible from those sides is the same. Besides, my current belief is that this is just the confusion between the SlotData.regno and kregs.regno. But yeah, messing with stuff that is known to work elsewhere is something I'd rather not do. - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFASmMZgAuWMgRGsWsRArniAJ91a619PYrS9RWC3SI27UQiNImJuQCfd4o4 CiSN+k+kYaD0p2bXcKIfUGg= =sfKZ -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Timothy Hmm, what are the error messages? The internal tests are Timothy pretty much the baby-steps, so you might want to pursue this Timothy first. The tests starts out simple with just trying to call Timothy functions, then passing parameters, then doing some Timothy arithmetic, and so on... I wrote them when I was working on Timothy the PowerPC backend and they were really helpful. Got it linked. Excellent! I get a bunch of assembly Yeah, those tests run with all of the debugging turned on. then this: Translating ParameterizedMethods.float_method_int_float_double_int(IFDI)F (static) 0x10067040 Failure 8fdc0010 123.456028 So this actually doesn't surprise me much: there appear to be bugs in the way float parameters are passed (and this, like isNaN, is static, so this probably limits the possibilities of what's wrong). Good, it looks like Kevin sent mail about this, so hopefully his suggestion helps a bit. Casey Marshall || [EMAIL PROTECTED] tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Hi Kevin, Kevin D. Kissell wrote: So this actually doesn't surprise me much: there appear to be bugs in the way float parameters are passed (and this, like isNaN, is static, so this probably limits the possibilities of what's wrong). In the period before kaffe 1.1.0, I identified a FP parameter passing problems in JIT3 for MIPS and fixed them in a couple of different ways, to the point where the TestNative regression test finally passed, and looking at my archives, as I posted to the mailing list last May, someone had checked in one of the effective fixes into kaffe.org. However, in looking at the CVSweb, it looks as if that fix never made it into the 1.1.0 tree. See my emails to the mailing list from March to June 2003 (there weren't that many of them). The minimalist fix was to flag f12 and f14 as Reserved and not just RFD in mips/jit.h, but the other fix, which involved replacing uses of rreg_float and rreg_double with uses of rreg_ideal_float and rreg_ideal_double in jit3-mips.def , would save a lot of useless spills. 1.1.0 was distinctly worse for JIT on MIPS than 1.0.7+. With a few fixes to 1.0.7, I was passing most of the regression tests, and I could even run the embedded Caffeinemark on a MIPSel Linux platform and get fairly decent performance. With 1.1.0, things went completely to hell. Oops, sorry about that :( I must have still been confused about using CVS properly back then. Could you repost the patch, so that I can check it into CVS HEAD? cheers, dalibor topic, taking things to hell and hopefully back ;) ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
I must have still been confused about using CVS properly back then. Could you repost the patch, so that I can check it into CVS HEAD? The system I use for kaffe development is down, and I'm up against some other deadlines that make it far from certain that I'll get around to reconstructing the environment and the patch any time soon. I'd strongly suggest that Casey try the following on his sources, rather than wait for me to get around to it. Go into kaffe/config/mips and edit jit.h. In the definition of REGISTER_SET (which goes on for a ways) where you see the string RFD in the rows for the FP argument passing registers f12 and f14, change that to RFD|Reserved. It would also be wise to change RIL to RIL|Reserved in the rows for integer registers i4, i5, i6, and i7. This will prevent a spill bug which causes arguments passed to JIT functions to be clobbered. Or at least it used to in the 1.0.7+ sources. This bug might not have been caught by the regression tests if it hadn't been for another significant defect of the MIPS JIT. JIT3 makes heroic efforts to track and preserve registers that contain interesting values for as long as possible. So every time you invoke rreg_float(), the register allocator (which was up in the architecture independent code) assigns a new register. If that register was previously used, it will be spilled to the stack. I guess the idea was that, if you never used up the full compliment of registers, you'd never have to spill. Unfortunately, it didn't take into account the fact that some register values have very short lifetimes, and the net result is that the entire register compliment can be forced into spills by a series of throw-away register uses. Specifically, in the definition of push_float kaffe/config/mips/jit3-mips.def, when NR_ARGUMENTS has been exceeded and we're passing arguments on the stack (the then it gets easy case), each new argument push invokes rreg_float(1), which allocates a FP register for the push. It's strictly a temporary value that can never be recycled, but if you pass 16 arguments, you'll clobber 16 distinct FPRs. I replaced the rreg_float(1) instance in push_float, and the rreg_double(1) with rreg_ideal_float(1, REG_f16) and rreg_ideal_double(1, REG_f16) respectively. This forced (well, sucessfully requested) that the designated floating temp register in the MIPS calling convention be used each time. The behavior was still sub-optimal, but preserved a lot more live registers than the way it had been when I found it. I'm going to resurrect my kaffe development environment one of these days and see if I can't help out more effectively on this stuff, but I can't imagine getting to it before the end of the month. Regards, Kevin K. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin == Kevin D Kissell [EMAIL PROTECTED] writes: I must have still been confused about using CVS properly back then. Could you repost the patch, so that I can check it into CVS HEAD? Kevin The system I use for kaffe development is down, and I'm up Kevin against some other deadlines that make it far from certain that Kevin I'll get around to reconstructing the environment and the patch Kevin any time soon. I'd strongly suggest that Casey try the Kevin following on his sources, rather than wait for me to get around Kevin to it. Kevin Go into kaffe/config/mips and edit jit.h. In the definition of Kevin REGISTER_SET (which goes on for a ways) where you see the Kevin string RFD in the rows for the FP argument passing registers Kevin f12 and f14, change that to RFD|Reserved. It would also be Kevin wise to change RIL to RIL|Reserved in the rows for integer Kevin registers i4, i5, i6, and i7. This will prevent a spill bug Kevin which causes arguments passed to JIT functions to be clobbered. Kevin Or at least it used to in the 1.0.7+ sources. This doesn't quite get around my initial problem (spilling a register with no ctype). Right now these are my suspicions/ideas: * The register managment code (spills/allocs/restores) appears to have changed to the point where it is incompatible with the way the MIPS backend presents its registers. Specifically, it looks like the register code likes to assume that the `regno' field is an index into the reginfo array, which isn't true for MIPS (it numbers its int registers from 0 to 31, then its float registers from 0 to 31 again). *Maybe* the register functions need to be a little smarter, by first choosing any register whose regno field matches the ideal number, then choosing the best register out of that set that fits the other criteria best. (This is all crash-course hacking I'm doing, so I might be totally mistaken). * If I renumber the float registers from 32 to 63, the spill problem doesn't happen, but I get a bus error when the `call' instruction is reached. This happens because the constant pool code tries to restore register gp from fp, and it looks like fp gets clobbered before this can happen. * If I disable the JIT constant pool, I get a segmentation fault. This happens because load_constant_int writes the return value of Float.isNaN(I)Z into register a0 (aka i4), and back in Float.toString [1] this register is used to reload itself (i.e. `lw a0,24(a0)'). This fails because that register now contains the result of a boolean method (1 or 0). So, it looks like there are some missing restores. These registers are spilled when they are used, but aren't restored. At any rate I'm still optimistic that this code is fixable without too much headache. [1] The stack that leads to this error is this: at java.lang.Float.toString(Float.java:98) at java.lang.StringBuffer.append(StringBuffer.java:432) at java.util.Hashtable.init(Hashtable.java:267) at java.util.Hashtable.init(Hashtable.java:122) at java.util.Properties.init(Properties.java:31) at java.util.Properties.init(Properties.java:27) at java.lang.System.clinit(System.java:44) at java.lang.Throwable.clinit(Throwable.java:403) at java.util.HashMap.init(HashMap.java:255) at java.util.HashMap.init(HashMap.java:113) at java.lang.ClassLoader.clinit(ClassLoader.java:78) And this looks very bad because I think the check !(DEFAULT_LOAD_FACTOR 0) fails, which is horribly, horribly wrong. - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFASM/lgAuWMgRGsWsRAjKZAJ0WAyT+NrzFLdOwZ3TBdEJi3+PMjACdE8lZ n9Yqzd9Q8gO4I4aiCKrrKG8= =QNt2 -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Right now these are my suspicions/ideas: * The register managment code (spills/allocs/restores) appears to have changed to the point where it is incompatible with the way the MIPS backend presents its registers. Specifically, it looks like the register code likes to assume that the `regno' field is an index into the reginfo array, which isn't true for MIPS (it numbers its int registers from 0 to 31, then its float registers from 0 to 31 again). It looks to me as if the MIPS numbering is done that way so that the synthesis of instructions can be done using regno, since MIPS FPRs and GPRs are in seperate banks and both addressed from 0 to 31. *Maybe* the register functions need to be a little smarter, by first choosing any register whose regno field matches the ideal number, then choosing the best register out of that set that fits the other criteria best. (This is all crash-course hacking I'm doing, so I might be totally mistaken). The rreg_ideal functions did more-or-less that, if I recall (it's been about a year since I did the same crash course your're doing now). * If I renumber the float registers from 32 to 63, the spill problem doesn't happen, but I get a bus error when the `call' instruction is reached. This happens because the constant pool code tries to restore register gp from fp, and it looks like fp gets clobbered before this can happen. The code generation in jit3-mips.def is going to generate all sorts of broken code if you allow those values to go above 31, I think. There is no masking of the shifted values as the instruction words are being created. You are very likely correct that the use of regno as an index is causing major problems, but I if you're going to renumber the floats, you need to tweak the instruction generation code. The minimalist hack would be to tweak some or all of the 9 macros at the top of jit3-mips.def to take advantage of the fact that 33 % 32 = 1, i.e. #define insn_RRR(op, rd, rs, rt) \ LOUT = 0x | ((rs) 21) | \ ((rt) 16) | ((rd) 11) | (op) would become #define insn_RRR(op,rd,rs,rt) \ LOUT = 0x | (((rs) 0x1f) 21) \ (((rt)0x1f)16) | (((rd)0x1f)11) op * If I disable the JIT constant pool, I get a segmentation fault. This happens because load_constant_int writes the return value of Float.isNaN(I)Z into register a0 (aka i4), and back in Float.toString [1] this register is used to reload itself (i.e. `lw a0,24(a0)'). This fails because that register now contains the result of a boolean method (1 or 0). So, it looks like there are some missing restores. These registers are spilled when they are used, but aren't restored. That's the syndrome that I was seeing that ORing Reserved into the descriptors for the argument registers seemed to help. That's fixing the symptom rather than the cause, though. It solves the problem by making sure that the argument registers won't be allocated for anything else, which would be wasteful as hell on a more register-poor architecture. The more correct fix would be to do the right thing (if only I knew exacltly what that was!) when arguments are being set up in registers, so that the registers are flagged as being valid even though the values weren't generated by the JIT. You might think that that's exaclty what's being done in places like the definition of push_double and push_float, when rreg_ideal_int() is being invoked on the argument registers, but empirically that wasn't the case when I looked into this last year. Regards, Kevin K. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
*Maybe* the register functions need to be a little smarter, by
first choosing any register whose regno field matches the ideal
number, then choosing the best register out of that set that fits
the other criteria best.
(This is all crash-course hacking I'm doing, so I might be
totally mistaken).
The rreg_ideal functions did more-or-less that, if I recall (it's been
about a year since I did the same crash course your're doing now).
Hmm, I think I ran into a similar problem rreg_ideal_int()... Here is an
excerpt from the pusharg_int section of the PowerPC backend:
if( (w = next_arg_register(a, Rint, r_count)) != -1 )
{
#if 0
/*
* We can pass the arg in a register. Ask for the register
* we were given (rreg_int(1)) to be mapped to the one we
* want (w).
*/
r = rreg_ideal_int(1, w);
if( r != w )
{
/* They weren't the same, flush whatever is in w */
clobberRegister(w);
/* and move the data into it. */
LOUT = ppc_op_mr(w, r);
/* XXX Why isn't there a register swap? */
}
/* Pin the register. */
register_reserve(w);
#else
/*
* can't use rreg_ideal_int because of brokeness. its possible
* for this to create a move between a callee saved register
* and a caller saved regsiter. And, since the pushargs are
* run after the function_sync that does the spill, we can lose
* the data in the register.
*/
r = rreg_int(1);
if( r != w )
{
clobberRegister(w);
LOUT = ppc_op_mr(w, r);
}
register_reserve(w);
#endif
And, here is the analogous section of the mips jitter:
if (arg_idx NR_ARGUMENTS) {
o = REG_i4 + arg_idx;
r = rreg_ideal_int(1, o);
/* We might not get the ideal register (if the slot is global)
* so handle this.
*/
if (r != o) {
clobberRegister(o);
insn_RRR(_ADDU, o, r, REG_i0);
debug((mov %s,%s\n, regname(o), regname(r)));
r = o;
}
register_reserve(r);
resreg[res_idx++] = r;
Perhaps you should try without the rreg_ideal_int()?
Regards,
Kevin K.
tim
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin == Kevin D Kissell [EMAIL PROTECTED] writes: * If I renumber the float registers from 32 to 63, the spill problem doesn't happen, but I get a bus error when the `call' instruction is reached. This happens because the constant pool code tries to restore register gp from fp, and it looks like fp gets clobbered before this can happen. Kevin The code generation in jit3-mips.def is going to generate all Kevin sorts of broken code if you allow those values to go above 31, Kevin I think. There is no masking of the shifted values as the Kevin instruction words are being created. I masked all the registers when generating instructions, and with the float registers renumbered all of the test/internal tests pass. Kaffe itself won't yet load, however. This solution is obviously a hack; the correct fix is probobly to fix register.c to not assume that regno is an index into reginfo. Unrelated question to the peanut gallery: currently the stack trace I get when Kaffe is loading (an Internal error: caught an unexpected exception.) goes all the way back to java.lang.VMThrowable.fillInStackTrace(VMThrowable.java:native). Is this just a symptom of an exception being thrown early, or is this yet another problem with the MIPS backend? - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFASQvdgAuWMgRGsWsRAoMrAKCHnDxQqb4F3Y/lXeTd5w7jUrHQxACeLKNP Sk21s4RmhYzHAntbg+My50s= =wQLR -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
But...but...the rreg_ideal variants are just invocations of slotRegister
(in kaffevm/jit3/registers.c) with a non-NOREG value in the idealreg
parameter. While having the NOREG value (i.e. using rreg_int() in
the examples below) will make it more likely that there's no need to
realocate and clobber a register, it doesn't guarantee it. And if there
*is* a need to reallocate, the same path will be taken for both the
ideal and non-ideal cases, the only difference being that in the
non-ideal case it will reallocate and clobber the least-recently-used,
rather than the specifically requested register. I could believe that
the hack below may have helped some bug that PPC was seeing,
and it might help MIPS as well, but if rreg_ideal_int() can be fatal,
I would think that rreg_int() could be as well.
/*
* can't use rreg_ideal_int because of brokeness. its possible
* for this to create a move between a callee saved register
* and a caller saved regsiter. And, since the pushargs are
* run after the function_sync that does the spill, we can lose
* the data in the register.
*/
r = rreg_int(1);
if( r != w )
{
clobberRegister(w);
LOUT = ppc_op_mr(w, r);
}
register_reserve(w);
#endif
And, here is the analogous section of the mips jitter:
if (arg_idx NR_ARGUMENTS) {
o = REG_i4 + arg_idx;
r = rreg_ideal_int(1, o);
/* We might not get the ideal register (if the slot is global)
* so handle this.
*/
if (r != o) {
clobberRegister(o);
insn_RRR(_ADDU, o, r, REG_i0);
debug(( mov %s,%s\n, regname(o), regname(r)));
r = o;
}
register_reserve(r);
resreg[res_idx++] = r;
Perhaps you should try without the rreg_ideal_int()?
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey == Casey Marshall [EMAIL PROTECTED] writes: Casey Secondly: if I hack slotRegister() to fill in ctype if it is Casey blank, I get further, but then Float.isNaN returns false when Casey given NaN, causing toCharArrayWithPrecision to barf. This has Casey got to be a mips-specific bug. floatToInt returns 0x for nan. This is most assuredly wrong, correct? - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFAR3SzgAuWMgRGsWsRAue4AJ9iM+v8T/q7iZ6MKHiEuKmFP8HgYwCfa04j KdJ43GgDj0g/VHVtz1E3jP0= =pxUa -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Hi, hi, I've started hacking around the JIT3 sources, and have found at least the first point of failure: spill() in jit3/register.c is being called in such a way that reginfo[s-regno].ctype is 0, i.e. it's type field is unset. This causes an immediate ABORT because there is (obviously) no way to spill an untyped register. s-regno has always been 12 when this happens, and this is the first time this register is ever spilled. What method is being jitted? Does the MIPS jitter pass all of the tests in the test/internal directory? Along the culprit's trail is a call to slotAlias (jit3/machine.c), which increments the reference count of reginfo[12], but leaves the ctype field untouched, so when that register is requested (push_float does this) it will be incorrectly spilled. Hmm, I'm a little concerned that the register set specification (REGISTER_SET in jit.h) is not quite right. Specifically, the regno fields are not unique, but the jitter is using them as an index into reginfo[]. Looking at the other jitters, I see both cases: The ARM and MIPS ones reuses the regno numbers. The i386, alpha, m68k, powerpc, and probably a few others use unique numbers. The safest bet is probably to renumber them and make sure any code that outputs floating point does the correct thing. So far I can't tell whether or not this is the fault of the mips-specific code, since I can't really get a stack trace far back enough. This isn't really related, but are you using the xdebugging infrastructure (see FAQ/FAQ.xdebugging)? I've found it quite helpful when working on the jitter. My suspicion is that the mips code doesn't properly free a register or slot, but I wanted to ask if anyone here has any idea why this situation might come up. Seems like integer register twelve was being used at the same time as floating point register twelve and there was some kind of conflict. But, it seems a little unlikely to have that many registers active... I'd have to see what code was being generated. Secondly: if I hack slotRegister() to fill in ctype if it is blank, I get further, but then Float.isNaN returns false when given NaN, causing toCharArrayWithPrecision to barf. This has got to be a mips-specific bug. Well, the most used code is the i386 stuff, which is pretty easy since it has so few registers. So, it is very possible that there is brokeness that has not been noticed yet. Cheers, - -- Casey Marshall || [EMAIL PROTECTED] tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timothy == Timothy Stack [EMAIL PROTECTED] writes: Hi, Timothy hi, I've started hacking around the JIT3 sources, and have found at least the first point of failure: spill() in jit3/register.c is being called in such a way that reginfo[s-regno].ctype is 0, i.e. it's type field is unset. This causes an immediate ABORT because there is (obviously) no way to spill an untyped register. s-regno has always been 12 when this happens, and this is the first time this register is ever spilled. Timothy What method is being jitted? Does the MIPS jitter pass all Timothy of the tests in the test/internal directory? java.lang.Float.toString. I can't seem to get jitBasic to staticly link, and thusfar all errors appear when kaffe is loading the core classes. Along the culprit's trail is a call to slotAlias (jit3/machine.c), which increments the reference count of reginfo[12], but leaves the ctype field untouched, so when that register is requested (push_float does this) it will be incorrectly spilled. Timothy Hmm, I'm a little concerned that the register set Timothy specification (REGISTER_SET in jit.h) is not quite right. Timothy Specifically, the regno fields are not unique, but the jitter Timothy is using them as an index into reginfo[]. Looking at the Timothy other jitters, I see both cases: Timothy The ARM and MIPS ones reuses the regno numbers. The i386, Timothy alpha, m68k, powerpc, and probably a few others use unique Timothy numbers. Timothy The safest bet is probably to renumber them and make sure any Timothy code that outputs floating point does the correct thing. I tried that (I changed the regno fields to go from 0 to 63) and I get a bus error. If this really is the solution then there are some other bugs. With these register infos changed the failure happens at Float.isNaN(float). So far I can't tell whether or not this is the fault of the mips-specific code, since I can't really get a stack trace far back enough. Timothy This isn't really related, but are you using the xdebugging Timothy infrastructure (see FAQ/FAQ.xdebugging)? I've found it quite Timothy helpful when working on the jitter. The GDB I am using isn't entirely functional, and so far everything I've been using needs to be staticly linked. - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFAR4regAuWMgRGsWsRAop1AJ9wwa3xaVYQkxLnq4NmeDhcuV9uoACfZCm6 7NkTa4Q7m8D0zYa7UVud3b4= =FB+j -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
Timothy What method is being jitted? Does the MIPS jitter pass all Timothy of the tests in the test/internal directory? java.lang.Float.toString. okie I can't seem to get jitBasic to staticly link, and Hmm, what are the error messages? The internal tests are pretty much the baby-steps, so you might want to pursue this first. The tests starts out simple with just trying to call functions, then passing parameters, then doing some arithmetic, and so on... I wrote them when I was working on the PowerPC backend and they were really helpful. thus far all errors appear when kaffe is loading the core classes. Yeah, it takes quite a few classes to get anywhere. Timothy The safest bet is probably to renumber them and make sure any Timothy code that outputs floating point does the correct thing. I tried that (I changed the regno fields to go from 0 to 63) and I get a bus error. If this really is the solution then there are some other bugs. With these register infos changed the failure happens at Float.isNaN(float). Well, it was worth a shot... Timothy This isn't really related, but are you using the xdebugging Timothy infrastructure (see FAQ/FAQ.xdebugging)? I've found it quite Timothy helpful when working on the jitter. The GDB I am using isn't entirely functional, and so far everything I've been using needs to be staticly linked. Oy... So does the add-symbol-file in gdb fail? Casey Marshall || [EMAIL PROTECTED] tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timothy == Timothy Stack [EMAIL PROTECTED] writes: I can't seem to get jitBasic to staticly link, and Timothy Hmm, what are the error messages? The internal tests are Timothy pretty much the baby-steps, so you might want to pursue this Timothy first. The tests starts out simple with just trying to call Timothy functions, then passing parameters, then doing some Timothy arithmetic, and so on... I wrote them when I was working on Timothy the PowerPC backend and they were really helpful. Got it linked. I get a bunch of assembly then this: Translating ParameterizedMethods.float_method_int_float_double_int(IFDI)F (static) 0x10067040 Failure 8fdc0010 123.456028 So this actually doesn't surprise me much: there appear to be bugs in the way float parameters are passed (and this, like isNaN, is static, so this probably limits the possibilities of what's wrong). - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFAR7GpgAuWMgRGsWsRAl/cAJ4lWy75Ch7sM4Kwi4tXYig+oZeaFQCeIk5g Hn0HJuj6DdfGsMgYcsFc5Aw= =j3zd -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FWIW, this is the current state of the tests in test/internal: ConstMathMethods.class:PASS ConstMethods.class:PASS ControlFlowMethods.class: PASS MethodOptimizations.class: PASS ObjectFields.class:FAIL (Bus error) ParameterizedBitwiseMethods.class: PASS ParameterizedLogicalMethods.class: PASS ParameterizedMathMethods.class:FAIL ParameterizedMethods.class:FAIL PrimitiveArrays.class: PASS StaticFields.class:FAIL (Segmentation fault) StaticMethodCall.class:FAIL (Bus error) TypeConversion.class: FAIL (Bus error) - -- Casey Marshall || [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQFAR7QxgAuWMgRGsWsRAnHDAJwPKhkPQfe7fHKo2Tkahwiox6LqsgCaAn6Q 63LsjBLXcFk6trKeiURgXdI= =ycVx -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] mipsel JIT3
So this actually doesn't surprise me much: there appear to be bugs in the way float parameters are passed (and this, like isNaN, is static, so this probably limits the possibilities of what's wrong). In the period before kaffe 1.1.0, I identified a FP parameter passing problems in JIT3 for MIPS and fixed them in a couple of different ways, to the point where the TestNative regression test finally passed, and looking at my archives, as I posted to the mailing list last May, someone had checked in one of the effective fixes into kaffe.org. However, in looking at the CVSweb, it looks as if that fix never made it into the 1.1.0 tree. See my emails to the mailing list from March to June 2003 (there weren't that many of them). The minimalist fix was to flag f12 and f14 as Reserved and not just RFD in mips/jit.h, but the other fix, which involved replacing uses of rreg_float and rreg_double with uses of rreg_ideal_float and rreg_ideal_double in jit3-mips.def , would save a lot of useless spills. 1.1.0 was distinctly worse for JIT on MIPS than 1.0.7+. With a few fixes to 1.0.7, I was passing most of the regression tests, and I could even run the embedded Caffeinemark on a MIPSel Linux platform and get fairly decent performance. With 1.1.0, things went completely to hell. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
