Hi JBG,
Thanks for the interest! Unfortunately, I need a few more days to work on this
patch to clean it up and fix a few more bugs, then I'll send out a new version
to NetBSD port-vax for testing, with ChangeLog entry. Please consider what I
sent out earlier to be a work-in-progress at this point.
The version I have on my machine is now generating bad code, after trying to
change a few "clobbers" to "compares", so I need to fix those bugs and also
further clean up some stuff that I know is broken. For example, there's some
old code in vax.c marked "#if HOST_BITS_PER_WIDE_INT == 32" and "if
(HOST_BITS_PER_WIDE_INT == 32)" that will never be used because HOST_WIDE_INT
is now always 64 (in hwint.h). I found another bug in a NetBSD command
(/usr/sbin/pkg_info) processing command-line arguments in main() that goes away
at "-O0". That bug should be easy to track down considering the small size of
the program and that it's failing immediately in main().
There's one more thing that's broken in the VAX backend which I'd *really* like
to fix: GCC can't compile many of its own files at -O2, as well as a few other
.c files in the NetBSD tree, because it can't expand an insn pattern. The
Makefiles have hacks to add "-O0" on VAX, and when I remove that workaround, I
get GCC assertion failures, all of the form:
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c: In function
'void maybe_emit_chk_warning(tree, built_in_function)':
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1: error:
unrecognizable insn:
}
^
(insn 295 294 296 25 (set (reg:SI 111)
(subreg:SI (mem:DI (plus:SI (mult:SI (reg:SI 109)
(const_int 8 [0x8]))
(reg/f:SI 45 [ D.85015 ])) [7 *_98+0 S8 A32]) 4))
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/wide-int.h:799 -1
(nil))
/home/netbsd/current/src/external/gpl3/gcc/dist/gcc/builtins.c:11549:1:
internal compiler error: in extract_insn, at recog.c:2343
0xbd0365 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:110
0xbd03fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/rtl-error.c:118
0xb92a2d extract_insn(rtx_insn*)
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/recog.c:2343
0x9612cd instantiate_virtual_regs_in_insn
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1598
0x9612cd instantiate_virtual_regs
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:1966
0x9612cd execute
/home/netbsd/current/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/function.c:2015
The failures all seem to be related to trying to read a value from an array of
64-bit values and loading it into a 32-bit register. It seems like there should
be a special insn defined for this sort of array access, since VAX has mova*
and pusha* variants to set a value from an address plus an index into a byte,
word, long, or 64-bit array (it uses movab/pushab, put not the other variants).
The addressing modes, constraints, and predicates all get very complicated, and
I still need to understand a bit better what is actually required, and what
could be simplified and cleaned up.
If anyone has suggestions on how to define an instruction that would solve the
previous failure, please let me know. Even without a special pattern for the
"(plus:SI (mult:SI (reg:SI) (const_int 8)))", it should be able to generate
something. It seems like it's expanding something and then the insn that's
supposed to go with it isn't matching.
I tried adding define_insns for "movstrictsi" and for "truncdisi2", hoping that
one of them would solve the "(set (reg:SI (subreg:SI (mem:DI (...)))))" part of
the situation, but it didn't help. The "(subreg:SI)" stuff is strange, and I
don't understand exactly what GCC is expecting the backend to define. I'll keep
working on things and as soon as I have something that I think is in a
contributable state and doesn't generate bad code, I'll email it.
Best regards,
Jake
> On Mar 31, 2016, at 07:30, Jan-Benedict Glaw <jbg...@lug-owl.de> wrote:
>
> Hi Jake!
>
> On Mon, 2016-03-28 16:34:56 -0700, Jake Hamby <jehamby...@me.com> wrote:
>> Amazingly enough, my patch worked well enough that my NetBSD VAX
>> kernel built with GCC 5.3 is no longer crashing. I feel pretty good
>> about what I have so far so here's the complete diff for both the
>> C++ exception fix and the bad condition codes optimizer bug. It
>> should be good enough to check into NetBSD current, at least, and I
>> believe it does fix most, if not all, of the bad code generation
>> bugs with optimization on VAX.
>
> I'd like to suggest to also Cc Matt Thomas <m...@3am-software.com>, at
> least once the patch is tested with GCC trunk/HEAD/master, instead of
> 5.3. There isn't probably much of a difference, but you've done
> substancial and important work here, so let's see it's applicable to
> upstream GCC.
>
> And keep in mind that a ChangeLog entry is also needed.
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
> Signature of: Ich hatte in letzter Zeit ein bißchen viel
> Realitycheck.
> the second : Langsam möchte ich mal wieder weiterträumen
> können.
> -- Maximilian Wilhelm (18. Mai 2005, #lug-owl.de)
