On 2015-07-18 08:24, Richard Henderson wrote:
> On 07/17/2015 11:33 AM, Aurelien Jarno wrote:
> >For now I do wonder if we shouldn't get the size changing extu/exts
> >mandatory instead of reusing the 64-bit only version. This doesn't
> >change the generated code, at least on x86.
>
> I'd be surprised if it did anywhere. I don't mind starting with them being
> required, and then figuring out a way to optimize.
I have a patch series ready for that if you want I can post it as RFC.
That said looking more deeply into the problem you found I guess we can
solve that easily by using the same convention than the real CPU for
storing 32-bit constants in the TCG optimizer.
This roughly means the following code for the 32-bit ops:
/* 32-bit ops generate 32-bit results. */
if (!(def->flags & TCG_OPF_64BIT)) {
if (!TCG_TARGET_HAS_ext_i32_i64) {
/* registers are maintained sign-extended */
mask = (int32_t)mask;
affected = (int32_t)mask;
} else if (!TCG_TARGET_HAS_extu_i32_i64) {
/* registers are maintained zero-extended */
mask = (uint32_t)mask;
affected = (uint32_t)mask;
} else {
/* high bits will be computed by ext/extu_i32_i64 */
mask = (uint32_t)mask;
affected = (uint32_t)mask;
}
}
And that would be fine for my patch series in preparation, as long as I
can predict the high part instead of considering it as garbage.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
