[0/8] Add optabs alternatives for insv, extv and extzv

[Richard Sandiford <rdsandiford@googlemail.com>]

This series was inspired by Andrew's patch from September:

    http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00126.html

and by a general frustration with the insv, extv and extzv interface.
The patches add 6 new optabs:

    insvM:          an M<-M register insertion
    insvmisalignM:  a BLK<-M memory insertion
    extvM:          a signed M<-M register extraction
    extvmisalignM:  a signed M<-BLK memory extraction
    extzvM:         an unsigned M<-M register extraction
    extzvmisalignM: an unsigned M<-BLK memory extraction

The BLKmode memory references are to the full bitfield, instead of
just a byte_mode memory reference to the first byte.  I used "misalign"
to emphasise that there's no alignment guarantee for the memory operand.

I've tried to leave open the possibility of having (aligned) M<-M memory
operations in future, but I haven't added them here because I have no
use case.  It's also not clear to me whether we'd want to generate the
memory form during expand or leave it up to combine.

The main target of this change is MIPS64r2, which can do both 32-bit and
64-bit insertions and extractions.  The current rtl code tends to do things
in 64 bits, because that's how the insv and ext(z)v interface is defined,
but doing things in 64 bits requires any 32-bit results to be explicitly
"truncated" (i.e. sign-extended).  Providing the optabs interface makes
both widths available.

Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .ii files.  On the other hand, the -march=octeon
output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
kicking in as hoped.

Richard