On 21 Jul 2006 10:06:34 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I also don't see why revision 108713 would affect this.
>
> But I do note that this version is still bad. The rdhwr instruction
> is in the branch delay slot, and is therefore always executed.
Yes, and I think rdhwr should not be in delay slot anyway. Just
avoiding delay slot is quite easy. Here is a proposal patch.
With this patch, it seems gcc 4.2 generate desired code for now,
though there might be somewhere to fix.
Index: gcc/config/mips/mips.md
===================================================================
--- gcc/config/mips/mips.md (revision 115370)
+++ gcc/config/mips/mips.md (working copy)
@@ -5450,6 +5450,9 @@
; MIPS 32r2 specification, but we use it on any architecture because
; we expect it to be emulated. Use .set to force the assembler to
; accept it.
+; Since rdhwr always generate a trap for now, it should not be be put
+; on delay slot. It it was on delay slot, the emulation will be
+; slower.
(define_insn "tls_get_tp_<mode>"
[(set (match_operand:P 0 "register_operand" "=v")
@@ -5458,6 +5461,7 @@
"HAVE_AS_TLS && !TARGET_MIPS16"
".set\tpush\;.set\tmips32r2\t\;rdhwr\t%0,$29\;.set\tpop"
[(set_attr "type" "unknown")
+ (set_attr "can_delay" "no")
(set_attr "mode" "<MODE>")])
; The MIPS Paired-Single Floating Point and MIPS-3D Instructions.
