Re: Bountysource campaign for gcc-vax

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Sat, 17 Oct 2020, Maciej W. Rozycki wrote:

> >  I've now completed lab setup up to being able to use it for this effort, 
> > and I have rerun testing with a new mighty server (a *proper* server, not 
> > a laptop).  This time results are not perfect either, but they are much 
> > better, though the execution time was a bit longer (still acceptable 
> > though), possibly due to the additional test cases that passed:
> > 
> > 		=== gcc Summary ===
> > 
> > # of expected passes		110142
> > # of unexpected failures	1821
> > # of unexpected successes	7
> > # of expected failures		566
> > # of unresolved testcases	30
> > # of unsupported tests		3131
> > /scratch/vol0/vax-netbsd/obj/gcc/gcc/xgcc  version 11.0.0 20200704 (experimental) (GCC)

 Current results:

		=== gcc Summary ===

# of expected passes		110140
# of unexpected failures	1822
# of unexpected successes	7
# of expected failures		566
# of unresolved testcases	30
# of unsupported tests		3131

which means there are no regressions anymore introduced by the conversion, 
because this:

>  FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
> +FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
> 
> i.e. the test failed at `-O0' already, and now it also fails at `-O2'.  
> Indeed:
> 
> /tmp/cc7MCwnm.s: Assembler messages:
> /tmp/cc7MCwnm.s:36: Warning: Symbol n used as immediate operand in PIC mode.
> FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
> 
> and:
> 
> /tmp/ccG0X3DQ.s: Assembler messages:
> /tmp/ccG0X3DQ.s:17: Warning: Symbol n used as immediate operand in PIC mode.
> /tmp/ccG0X3DQ.s:26: Warning: Symbol n used as immediate operand in PIC mode.
> FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
> 
> indicate some RTL pattern incorrectly permits a symbolic (i.e. link-time) 
> constant as an instruction operand where an assembly-time constant only is 
> supported with the PIC ABI.  This will be easy to track down, though it 
> qualifies as a separate bug fix.

has indeed turned out to be an unrelated issue: with a fix to PR lto/67548 
the LTO compiler has been strapped to produce non-PIC code for executable 
builds:

    case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */
      flag_pic = 0;
      flag_pie = 0;
      flag_shlib = 0;
      break;

which obviously breaks with our port as we have the default of `-fPIC' 
(and `-KPIC' for GAS) for code generation.  I'll file a PR to track this.

 The remaining issues turned out to be a result of the mess we have with 
RTL instruction predicates and constraints in the VAX machine description.  
For some reason (probably attempts made by hand to avoid certain operand 
classes with some machine instructions for code scheduling/performance 
reasons) we use different predicates and constraints for the same kind of 
operand across various machine instructions.

 E.g.:

(define_insn "*cmp<mode>"
  [(set (cc0)
	(compare (match_operand:VAXint 0 "nonimmediate_operand" "nrmT,nrmT")
		 (match_operand:VAXint 1 "general_operand" "I,nrmT")))]
  ""
  "@
   tst<VAXint:isfx> %0
   cmp<VAXint:isfx> %0,%1")

has a predicate that does not allow an immediate in operand #0 (and it 
also uses the `n' constraint that does), even though there's nothing in 
the architecture that would prevent one from using an immediate as the 
first operand to CMP or the sole operand to TST instructions.  So it can 
be `general_operand' for both RTL instruction operands.

 Similarly:

(define_insn ""
  [(set (match_operand:SI 0 "nonimmediate_operand" "=g")
	(sign_extract:SI (match_operand:SI 1 "register_operand" "ro")
			 (match_operand:QI 2 "general_operand" "g")
			 (match_operand:SI 3 "general_operand" "nrmT")))]
  ""
  "*
{
  if (! CONST_INT_P (operands[3]) || ! CONST_INT_P (operands[2])
      || ! REG_P (operands[0])
      || (INTVAL (operands[2]) != 8 && INTVAL (operands[2]) != 16))
    return \"extv %3,%2,%1,%0\";
  if (INTVAL (operands[2]) == 8)
    return \"rotl %R3,%1,%0\;cvtbl %0,%0\";
  return \"rotl %R3,%1,%0\;cvtwl %0,%0\";
}")

has a predicate that does not allow a memory reference in operand #1, but 
uses the `o' constraint which does and can use the `nonimmediate_operand' 
predicate instead.

 With all the regressions out of the way the next step is code quality, 
which has become a little lower, so it has to be addressed now.

  Maciej