On Wed, Oct 17, 2012 at 11:55 AM, Eric Botcazou wrote:
>> Maybe add a cost-free dependency on the clobber, so that it's moved
>> with the insn?
>
> Maybe.  But I'm a little worried about (1) extending the lifetime of the hard
> register and (2) simply moving around a clobber of a hard register.

AFAIU the clobber is there because it was emitted specially for this
particular use of the hard register. So moving it around with the
reason why it's there in the first place would make sense to me.

I don't understand what you mean with extending the life of the hard
register in this case. If you move the clobber with the instruction,
the hard reg is dead before the clobber and after the insn that uses
it, just like when the insn is not hoisted from the loop. So you don't
extend the reg's live range if you move the clobber with it. And if
the register is not dead after the insn, it must be live through the
loop (otherwise it would be only partially available on the loop
entry, coming in from the loop latch) so you don't extend the live
range in that case either.


(One thing I don't fully understand here, though, is why the clobber
doesn't prevent the code motion to begin with. If you don't move the
clobber, that could change the semantics of the program, right? E.g if
you have before LIM something like this:

  while (some_condition) { clobber(ecx); invariant_use (ecx);  ... };
  use (ecx);

and after LIM you have:

  invariant_use (ecx);
  while (some_condition) { clobber(ecx);  ... };
  use (ecx);

that's not the same program anymore if some_condition isn't true...
Not sure if that matters for this kind of uninitialized use.)


> I'd like to keep the change minimal, in particular restricted to uninitialized
> hard registers.  The failure mode is very specific (and might be unique to the
> 64-bit ABI on Windows) so I'm not sure it's worth generalizing.

I've got a great dislike for special cases in the GCC code base, they
tend to grow into common practice at alarmingly fast rates :-)
But I suppose your point of view is more pragmatic in this peculiar case.

Ciao!
Steven

Reply via email to