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

On 04/04/2016 08:51 AM, Maciej W. Rozycki wrote:

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.

Note you shouldn't need an expander for this.
That insn is just a 32bit load. I would have expected something to simplify the subreg expression, likely requiring loading the address into a register in the process. 

Jeff
Home | Main Index | Thread Index | Old Index