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

[Maciej W. Rozycki]

On Thu, 31 Mar 2016, Jake Hamby wrote:

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

 Please note however that this RTL instruction is a memory reference, not 
an address load.  So the suitable hardware instruction would be MOVAQ for 
an indexed DI mode memory load.  If used to set a SI mode subreg at byte 
number 4 (this would be the second hardware register of a pair a DI mode 
value is held in) as seen here, it would have to address the immediately 
preceding register however (so you can't load R0 this way) and it would 
clobber it.

 So offhand I think you need an RTL instruction splitter to express this, 
and then avoid fetching 64 bits worth of data from memory -- for the sake 
of matching the indexed addressing mode -- where you only need 32 bits.  
At the hardware instruction level I'd use a scratch register (as with 
MOVAQ you'd have to waste one anyway) to scale the index and then use 
MOVAL instead with the modified index.  Where no index is used it gets 
simpler even as you can just bump up the displacement according to the 
subreg offset.

 HTH,

  Maciej