Re: VAX backend status

2007-04-05 Thread Paolo Bonzini
I've noticed a few things in doing the above. GCC 4.x doesn't seems to do CSE on addresses. Because the VAX binutils doesn't support non-local symbols with a non-zero addend in the GOT, PIC will do a define_expand so that (const (plus (symbol_ref) (const_int))) will be split into separate

Re: VAX backend status

2007-04-04 Thread Ian Lance Taylor
Matt Thomas [EMAIL PROTECTED] writes: Over the past several weeks, I've revamped the VAX backend: - fixed various bugs - improved 64bit move, add, subtract code. - added patterns for ffs, bswap16, bswap32, sync_lock_test_and_set, and sync_lock_release - modified it to

Re: VAX backend status

2007-04-02 Thread Toon Moene
Matt Thomas wrote: For instance, gcc emits: movab rpb,%r0 movab 100(%r0),%r1 cvtwl (%r1),%r0 but the movab 100(%r0),%r1 is completely unneeded, this should have been emitted as: movab rpb,%r0 cvtwl 100(%r0),%r0 Ah ! A clear case of all the world's a

Re: VAX backend status

2007-04-02 Thread Andrew Pinski
On 4/2/07, Toon Moene [EMAIL PROTECTED] wrote: Ah ! A clear case of all the world's a RISC syndrome. Actually I think it is a case of CSE/frowprop not doing the correct thing for the addressing modes. So it might be the real problem is the back-end's addressing mode cost are incorrect or

VAX backend status

2007-04-01 Thread Matt Thomas
Over the past several weeks, I've revamped the VAX backend: - fixed various bugs - improved 64bit move, add, subtract code. - added patterns for ffs, bswap16, bswap32, sync_lock_test_and_set, and sync_lock_release - modified it to generate PIC code. - fixed the dwarf2 output so it is