Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Patches to fix optimizer bug & C++ exceptions for GCC VAX backend



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 <jbglaw%lug-owl.de@localhost> wrote:
> 
> Hi Jake!
> 
> On Mon, 2016-03-28 16:34:56 -0700, Jake Hamby <jehamby420%me.com@localhost> 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 <matt%3am-software.com@localhost>, 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      jbglaw%lug-owl.de@localhost              +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)



Home | Main Index | Thread Index | Old Index