Re: [RFC] Fix spill failure at -O on 64-bit Windows

[Eric Botcazou <ebotcazou@adacore.com>]

> 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.

In the former case, I agree that you don't really extend the live range.
But you nevertheless extend its "span", i.e. you create a live range for the 
hard register out of the loop, while it's supposed to be used only just before 
the call in the argument preparation.  In the latter case, I'm not sure that 
your conclusion holds: why can't it be used in a second insn and die there?

> (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 agree that moving an uninitialized use (of a hard register) without moving 
the associated clobber is weird.  But I think most RTL passes don't care and 
this probably doesn't affect the correctness of the generated code.

> 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.

I'm just realistic: you don't want to make substantial changes in a powerful 
optimization pass just because of a corner case in an exotic language on a 
semi-exotic platform. :-)

-- 
Eric Botcazou