[Lightning] Lightning Itanium port

[Paulo César Pereira de Andrade]

  Hi,

  Just a minor heads up. I am almost done with an Itanium lightning
port, so that there will be only one architecture in the gcc build farm [1]
missing a port (hppa).
  An aarch64 port would be the hot thing to do, but it is still too hot :-)
so, I will wait a bit more.
  This is being done to also check for possible extra issues in
lightning, before making an official release of the rework intended
for "lightning 2.0".

  Sample output:
---%<---
address@hidden:~/lightning-2.0/check$ cat hello.tst
.data   32
hello:
.c      "Hello world!\n"

.code
        prolog
        prepare
                pushargi hello
                ellipsis
        finishi @printf
        ret
        epilog

address@hidden:~/lightning-2.0/check$ ./lightning -v hello.tst
 0x2000000000794000     [MIB]       break.m 0xf28
 0x2000000000794006                 break.i 0x200
 0x200000000079400c                 break.b 0x0
 0x2000000000794010     [MII]       alloc r41=ar.pfs,14,12,0
 0x2000000000794016                 nop.i 0x0
 0x200000000079401c                 nop.i 0x0
 0x2000000000794020     [MII]       mov r42=r12
 0x2000000000794026                 mov r40=b0
 0x200000000079402c                 nop.i 0x0
 0x2000000000794030     [MII]       mov r43=r1
 0x2000000000794036                 mov r3=96;;
 0x200000000079403c                 sub r4=r12,r3
 0x2000000000794040     [MMI]       mov r3=96;;
 0x2000000000794046                 nop.m 0x0
 0x200000000079404c                 sub r12=r12,r3
 0x2000000000794050     [MLX]       nop.m 0x0
 0x2000000000794056                 movl r44=0x6000000000039e30
 0x2000000000794060     [MLX]       nop.m 0x0
 0x2000000000794066                 movl r3=0x200000000004e7c0;;
 0x2000000000794070     [MMI]       ld8 r9=[r3],8;;
 0x2000000000794076                 nop.m 0x0
 0x200000000079407c                 mov b6=r9
 0x2000000000794080     [MBB]       ld8 r1=[r3]
 0x2000000000794086                 br.call.sptk.many b0=b6
 0x200000000079408c                 nop.b 0x0;;
 0x2000000000794090     [MII]       mov r1=r43
 0x2000000000794096                 mov.i ar.pfs=r41
 0x200000000079409c                 mov b0=r40
 0x20000000007940a0     [MMI]       mov r12=r42;;
 0x20000000007940a6                 nop.m 0x0
 0x20000000007940ac                 adds r4=96,r12
 0x20000000007940b0     [BBB]       br.ret.sptk.many b0
 0x20000000007940b6                 nop.b 0x0
 0x20000000007940bc                 nop.b 0x0
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hello world!
address@hidden:~/lightning-2.0/check$
---%<---

  It has some significant overhead, as most other ports, e.g.
it always "alloc's" income registers, even when there are
no arguments, does not properly check&optimize leaf
functions, neither reorder instructions to reduce code
size, but has a simple buffer for inserting stops to
break instruction groups when a register/predicate is
written and read (or modified more than once) in an
instruction group.  But overall the overhead is not too
high, and should at least match equivalent "gcc -O0"
code generation performance/size.

  As of the writing of this email, the only test cases
failing are the ones testing stack arguments for functions
with too many arguments (what should be a very uncommon
usage of lightning, and only "stub" logic was added to
handle it so far, most likely only need to update the stack
offset calculation):
[...]
FAIL: varargs
FAIL: stack
[...]
FAIL: ccall
[...]
# TOTAL: 42
# PASS:  39
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0


  As usual, if you want to play with the current code, check:

http://savannah.gnu.org/git/?group=lightning

Thanks,
Paulo

[1] http://gcc.gnu.org/wiki/CompileFarm