[PATCH 1/3] SH-2A FDPIC: New pattern: use_initial_val

[Bernd Schmidt]

On 08/19/2010 08:42 PM, Richard Henderson wrote:
> On 08/19/2010 11:30 AM, Bernd Schmidt wrote:
>>> Looking forward to 3/3, it seems you emit a fancy USE insn, whose
>>> purpose appears to be simply to extend the lifetime of the pseudo,
>>> without actually using it in a specific pattern.
>>
>> Yes.  It's an unspec which later gets turned into a no-op.
> 
> Looking at the split, it really does turn in to a nop insn, not
> being optimized away entirely.  Is that really intended?  If so,
> I think that deserves a comment.

AFAIR no code is output for it.  If that's not true, then that at least
needs to be revisited.  Does the splitting code handle the case where we
return no insn at all?

> What advantage does this unspec have over a (USE reg) insn?

I wasn't certain a USE wouldn't just get deleted, now or in the future,
if it was the only remaining use of a pseudo.

> I'm somewhat surprised that a free-floating use or unspec does
> what you want better than actually using the pseudo in some
> insn pattern that actually requires it.  E.g. by adding it to
> the CALL_INSN_FUNCTION_USAGE where optimize_mode_switching can
> find it.
>
> Can you tell me which part of mode switching ends up requiring
> the pseudo?  Scanning the 3/3 patch, it's non-obvious.

I don't have the build trees anymore, and I don't recall all the details
- but I think it was generating a reference to a symbol, which required
the PIC register.  I believe it was __fpscr_values - see emit_fpu_switch
in sh.c.
For FD-PIC, the incoming PIC reg is loaded into a pseudo with the
initial values machinery.  The problem occurs if during expand we
already had something that required the PIC register, so the pseudo was
set up, but all the uses (and hence the initializing insn) were
optimized away.  So there really isn't anywhere to put it anymore in
this case.


Bernd