Re: [Qemu-devel] [PATCH 0/4] tcg: Add debug facilities for TCGv

[Paul Brook]

> > What mismatches does this catch that the existing debug code doesn't?
> 
> Cf. patch 4/4:
> 
> TCGv tmp = tcg_temp_new_i32();
> tcg_temp_free_i32(tmp);
> 
> TCGv_i32 tmp2 = tcg_temp_new();
> tcg_temp_free(tmp2);

Why is this a problem?  If TARGET_LONG_BITS==32 then tcg_temp_free and 
tcg_temp_free_i32 are synonyms, and everything is happy.

If TARGET_LONG_BITS==64 then we already flag this as an error.

> Try compiling --target-list=arm-softmmu --enable-debug-tcg with my
> series and DEBUG_TCGV_TL uncommented, and you'll see for yourself.
> There's too many to mention and for me to actually fix. You'll have to
> deal with it for ARMv8 at some point and this series hopefully helps.

That's exactly why I think this patch is a bad idea.

If a target always has TARGET_LONG_BITS==32 then it doesn't matter if we mix 
TCGv and TCGv_i32.

If a target has both 32-bit and 64-bit variants then at least one of these 
will already fail to build.  I don't see how making both fail provides any 
benefit.  As you say, whoever implements ARMv8 gets to fix all the mismatches 
when thay actually add the aarch64 support.

Trying to make a 32-bit target "64-bit safe" without actually implementing the 
64-bit target is a complete waste of time.  You've almost no chance of getting 
it right.  In some cases the correct answer will be to use 32-bit arithmetic, 
then sign/zero extend the result. In other cases the correct answer will be to 
perform word size arithmetic.  Blindly picking one just makes the bugs harder 
to find later.

If you're trying to add support for targets where the primary word size is 
neither 32 nor 64 then that's a completely different problem, and probably not 
one that's worth solving.  In practice your port is going to end up using 64-
bit arithmetic and explicitly compensating for the excess precision where 
necessary.

Paul