[MIPS][LS2][4/5] Scheduling and tuning
Maxim Kuvyrkov
maxim@codesourcery.com
Sun Jun 15 17:28:00 GMT 2008
Richard Sandiford wrote:
> Maxim Kuvyrkov <maxim@codesourcery.com> writes:
>> Richard Sandiford wrote:
>>> FWIW, this is PR 35802. 'Fraid I still haven't had chance to look at it,
>>> what with IRA, recog-related stuff and reviews.
>> ...
>>
>>> We have two choices:
>>>
>>> - always use pseudo registers, rather than introducing uses of $3
>>> from the outset
>>>
>>> - force the destination of tls_get_tp_<mode> to be $3 only.
>> I don't see how first approach can be any better than second. We will
>> allocate register $3 for all those pseudos in the end.
>
> The first approach is better if it works because some passes can only
> optimise things that can have pseudo destinations. E.g. after the patch,
> gcse won't be able to optimise these patterns.
>
> The ICE currently only occurs when a pass has made such a replacement,
> presumably because it thought that the change was an improvement.
> I imagine that the patch I posted prevents something that we thought
> was an optimisation in your testcase.
>
> That's the big drawback of the second approach. These instructions
> are emulated on the vast majority of processors, so we're losing
> the ability to optimise very expensive instructions.
>
> But like I say, I'm not convinced the first approach is going to avoid
> the ICE in all cases. We have a PR against a release branch, so in the
> first instance, I think we need something that is safe over something
> that leads to better optimisation.
>
> A third alternative is to use ugly workarounds like:
>
> (define_insn "tls_get_tp_<mode>"
> [(set (match_operand:P 0 "register_operand" "=v,???d")
> (unspec:P [(const_int 0)]
> UNSPEC_TLS_GET_TP))]
> "HAVE_AS_TLS && !TARGET_MIPS16"
>
> and make the second alternative use a sequence like:
>
> move $1,$3
> rdhwr $3,$29
> move %0,$3
> move $3,$1
>
> which is _usually_ going to be a win in cases where it avoids a further
> rdhwr instruction at runtime. But it would lose otherwise.
>
> This too should be safe, either on its own or in combination with
> the first approach.
>
> But longer-term, I think we need to do something less hacky that
> still allows the optimisations. I'm just not sure what yet. ;)
Oh, I can't suggest any better alternative than those you outlined
above. Shout if you need any help testing the eventual fix.
>>> The second is probably the most conservative approach, since explicit
>>> uses of $3 can occur through normal calls. The patch below does this.
>>>
>>> I admit I haven't verified any of this yet, so sorry if I'm off-ball.
>>> But does the patch fix things?
>> Looks like it does. I didn't run full regression testsuite, but glibc
>> now builds.
>
> Great, thanks. I'll think a bit more about this before installing anything.
> You needn't wait before applying your patches.
I've applied the scheduling patch today. Thanks for the review.
--
Maxim
More information about the Gcc-patches
mailing list