Re: [Qemu-devel] [PATCH 3/3] tcg/arm: improve constant loading

[Aurelien Jarno]

On Fri, Jan 07, 2011 at 04:56:32PM +0100, andrzej zaborowski wrote:
> On 7 January 2011 15:40, Aurelien Jarno <address@hidden> wrote:
> > On Fri, Jan 07, 2011 at 01:52:25PM +0100, andrzej zaborowski wrote:
> >> Hi,
> >>
> >> On 6 January 2011 22:54, Aurelien Jarno <address@hidden> wrote:
> >> > Improve constant loading in two ways:
> >> > - On all ARM versions, it's possible to load 0xffffff00 = -0x100 using
> >> >  the mvn rd, #0. Fix the conditions.
> >> > - On <= ARMv6 versions, where movw and movt are not available, load the
> >> >  constants using mov and orr with rotations depending on the constant
> >> >  to load. This is very useful for example to load constants where the
> >> >  low byte is 0. This reduce the generated code size by about 7%.
> >>
> >> That's a nice improvement.  For some instructions using MVN and AND
> >> could yield even shorter code and I think with that the optimisation
> >> options (except loading from a constant pool) would be exhausted :)
> >
> > I also did something with MVN and BIC, it works well, but the problem is
> > to find the right heuristic to choose between MOV/ORR and MVN/BIC. In my
> > tries, it was making the code bigger.
> 
> I was thinking of running both without writing the instructions, then
> comparing the lengths and then running the better method.  It's
> possible that the cost of this outweights the shorter code advantage
> though.
> 
> >
> >> ...
> >> >         }
> >> > +    } else {
> >> > +        int opc = ARITH_MOV;
> >> > +        int rn = 0;
> >> > +
> >> > +        do {
> >> > +            int i, rot;
> >> > +
> >> > +            i = ctz32(arg) & ~1;
> >> > +            rot = ((32 - i) << 7) & 0xf00;
> >> > +            tcg_out_dat_imm(s, cond, opc, rd, rn, ((arg >> i) & 0xff) | 
> >> > rot);
> >> > +            arg &= ~(0xff << i);
> >> > +
> >> > +            opc = ARITH_ORR;
> >> > +            rn = rd;
> >>
> >> I think you could get rid of rn and just use rd from the start of the
> >> loop.  Otherwise acked by me too.
> >>
> >
> > What do you mean exactly? rn has to be 0 when opc is ARITH_MOV in order
> > to generate a correct ARM instruction.
> 
> According to my ARM926 manual rn is ignored for MOV/MVN, perhaps it's
> different in later revisions.
> 

I have just tried, and it actually works (tried on ARMv5 and ARMv7). 
Note that binutils is not able to disassemble such an instruction and
outputs in qemu.log something like:
| 0x01000008:  e3aa50ff  undefined instruction 0xe3aa50ff

However what worries me the most is that the "ARM Architecture Reference
Manual ARMv7-A and ARMv7-R edition" defines this opcode with the rn field
as "(0)(0)(0)(0)". Looking at what it means:

| An instruction is UNPREDICTABLE if:
| [...]
| * the pseudocode for that encoding does not indicate that a different
|   special case applies, and a bit marked (0) or (1) in the encoding 
| diagram of an instruction is not 0 or 1 respectively.

In short is it still going to work on newer CPUs?

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net