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 r
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
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
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 t
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 inst