This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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 assembler branch relaxations


On Sun, Sep 15, 2002 at 01:39:27AM -0300, Alexandre Oliva wrote:
> On Sep 14, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > If this goes in as-is, I doubt that it'll ever be done the right way. 
> 
> I agree.  I doubt it's worth doing it the right way.  It shouldn't
> strike often enough to motivate anyone to do it.
> 
> > Does it happen inside .set nomacro? [I think so - should it?  I'd
> > say not!]
> 
> I don't see why not.  It's not like we're expanding a macro.  We're
> rather doing relaxation.  Does the linker refrain from doing
> relaxations on machine code generated from opcodes assembled while
> .set nomacro was in effect?  This is no different, except that the
> relaxation is being performed in the assembler rather than in the
> linker.

I suppose.  But, as I've been discussing with Eric, the eventual goal
is for GCC to not emit macros; which will let it have much more precise
control over the generated code.  That'll make overlong branches
significantly less likely, and more interesting to know about.  I guess
a warning would suffice.

> > I think there should be a command-line option to disable this,
> > and/or warn about it.
> 
> That would be a nice improvement.  Just arrange for whatever option
> you come up with to disable this block:
> 
>   if (place == NULL
>       && address_expr
>       && ((*reloc_type == BFD_RELOC_16_PCREL
> 	   && address_expr->X_op != O_constant)
> 	  || *reloc_type == BFD_RELOC_16_PCREL_S2)
>       && (pinfo & INSN_UNCOND_BRANCH_DELAY || pinfo & INSN_COND_BRANCH_DELAY
> 	  || pinfo & INSN_COND_BRANCH_LIKELY)
> +     && !whatever_option_you_come_up_with
>       && !mips_opts.mips16)
> 
> This will switch all the rest off.

Thanks.  How about something as simple as -mno-relax-branch?  (Or would
it be -no-mrelax-branch?  Gas is pretty inconsistent.)

I suppose warning by default would be a little too harsh, too.  With
the option to not relax it would be as simple as running a GCC testsuite
with unix/-Wa,-mno-relax-branch.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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