This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS RDHWR instruction reordering


On 16 Jun 2006 14:12:29 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > The RDHWR is executed _before_ evaluating the "arg" value.  For arg ==
> > 0 case, the RDHWR has no point but just a overhead.  Without -O2, the
> > RDHWR is executed _after_ the evaluation, so gcc's optimizer reorder
> > the RDHWR instruction.
> 
> The computation of the address of x was moved outside the
> conditional--that is, both the rdhwr and the addu moved.  You'll have
> to figure out why.  gcc shouldn't move instructions outside of a
> conditional unless they are cheap and don't trap.  This instruction
> doesn't trap, but it's not cheap.

AFAIK on all MIPS CPU the rdhwr generates an exception (trap).

I tried changing "unspec" to "unspec_volatile" in this definition:

(define_insn "tls_get_tp_<mode>"
  [(set (match_operand:P 0 "register_operand" "=v")
	(unspec:P [(const_int 0)]
		  UNSPEC_TLS_GET_TP))]
  "HAVE_AS_TLS && !TARGET_MIPS16"
  ".set\tpush\;.set\tmips32r2\t\;rdhwr\t%0,$29\;.set\tpop"
  [(set_attr "type" "unknown")
   (set_attr "mode" "<MODE>")])

With "unspec_volatile", gcc do not move the rdhwr before the branch.
But this change has bad side effects.  For example, if I incremented a
thread local variable, rdhwr is used twice (for load and store).

So I suppose we should tell gcc that rdhwr is not cheap.  But I do not
know how to describe such information in .md file...

---
Atsushi Nemoto


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]