On 2015-07-29 21:42, Alex Bennée wrote:
>
> Aurelien Jarno <aurel...@aurel32.net> writes:
>
> > On 2015-07-29 17:12, Alex Bennée wrote:
> >>
> >> Aurelien Jarno <aurel...@aurel32.net> writes:
> >>
> >> > Now that copies and constants are tracked separately, we can allow
> >> > constant to have copies, deferring the choice to use a register or a
> >> > constant to the register allocation pass. This prevent this kind of
> >> > regular constant reloading:
> >> >
> >> > -OUT: [size=338]
> >> > +OUT: [size=298]
> >> > mov -0x4(%r14),%ebp
> >> > test %ebp,%ebp
> >> > jne 0x7ffbe9cb0ed6
> >> > mov $0x40002219f8,%rbp
> >> > mov %rbp,(%r14)
> >> > - mov $0x40002219f8,%rbp
> >> > mov $0x4000221a20,%rbx
> >> > mov %rbp,(%rbx)
> >> > mov $0x4000000000,%rbp
> >> > mov %rbp,(%r14)
> <snip>
> >> > --- a/tcg/optimize.c
> >> > +++ b/tcg/optimize.c
> >> > @@ -237,11 +237,6 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp
> >> > *op, TCGArg *args,
> >> > return;
> >> > }
> >> >
> >> > - if (temp_is_const(src)) {
> >> > - tcg_opt_gen_movi(s, op, args, dst, temps[src].val);
> >> > - return;
> >> > - }
> >> > -
> >>
> >> That looks suspicious, surely we only want to drop the move if we
> >> already have the const somewhere else?
> >
> > That's actually the while point of this patchset, to avoid converting
> > mov into moving for constant values and thus loosing the link between
> > temps.
>
> I get that, I guess I didn't follow the previous loading of the constant
> value. Maybe showing the ops in the commit message will make it clearer.
Ok, I'll do that in v3.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
