This is the mail archive of the 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: [patch] new cpu sr71k

At Fri, 13 Sep 2002 11:57:44 -0700, Mark D. Baushke wrote:
> > (Users should be able to use -mbranch-likely to override the default,
> > which this patch does not allow.)
> Hmmm... If the cpu does not support any branch-likely instructions, then
> even use of -mbranch-likely should not generate those instructions,

I'm of a slightly different mind about this:

If the user asked for them specifically, they should get them.  (Note
that they should also get a warning... which they do.  8-)

I believe the code handles this adequately already.

(There are reasons for this.  e.g., you're testing code for a
processor that in general case has bugs that preclude their use, but
you specifically want to enable them for your test.  or, you're
testing a new rev of the processor which fixes them, and you don't
want to generate new tools.  or, you're trying to trick the compiler,
e.g. by using only mipsI instructions for the most part, but adding-in
branch-likelys because you know it's safe on your part/for your
code.  8-)

> > (It occurs to me that I should add TUNE_SB1 into the code in mips.c,
> > to express a preference regardless of ISA_*.)
> >
> > thoughts?
> Possibly. If someone uses -mtune=sb1 does that mean that instructions
> that would stop any of the other mips variants from working properly
> should be chosen? I didn't think that was the purpose. For that you
> would want to sue -march=sb1 right?


You'd use the tune flags like the following, in that code to set the

	if (the isa/arch supports them
	    && (!(an isa/arch or tune that strongly discourages them)
		|| (a tune that strongly encourages them despite isa)))


	    && (!(ISA_MIPS32
		  || ISA_MIPS64
		  || TUNE_SB1
		  || TUNE_something1
		|| (TUNE_something2
		    || ...)))
	} else {

in this example:

'something1' is a processor for an arch that normally allows
them, but on which there are negative performance implications from
their use.

'something2' is a process for an arch that would normally disallow
them (e.g. MIPS32 / MIPS64) but which really really likes them.
(Given that MIPS32 and MIPS64 _do_ deprecate their use, I'm not sure
that it's wise to allow this case.  I think if people want to turn
them on and override the default to no for those ISAs, it's reasonable
to say that those people should have to say -mbranch-likely... but I
don't feel that way _too_ strongly.  8-)


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