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: CSE & compare/branch template problem


Joern Rennecke wrote:
Quoting Michael Eager <eager@eagercon.com>:

Hi --

I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.

In theory cstore / cbranch should be the future, but the last time I tried to use them, they didn't quite work right yet, particularily if you have an incomplete comparison set. Because of delays with the Copyright assignment, fixing the middle-end was not an efficient option, so I went for the old hack with separate compare and condjump / cstore patterns.

Thanks. That's good to know.



Somehow, CSE is deciding that reg 137 is equal to zero and
translates insn 99 to

(insn 99 98 100 3 .../strchr.c:93
  (set (reg:CC 249)
       (eq:CC
           (reg:SI 247)
           (reg/v:SI 137 [ c+-3 ]))) 71

That is correct; after the jump_insn 94 is not taken, you can conclude that reg 137 is zero.

Urk. After stepping through the code and seeing that the hw reg allocated to reg 137 was non-zero, I looked at the insns and (incorrectly) decided that CSE had been wrong. I think I managed to confuse myself since reg 246 is 1 if reg 137 is 0.

This means that the instruction generated for the compare or
the branch is incorrect.  That's easier than chasing after a
non-existent CSE bug.

Thanks for pointing this out.


  Are there other targets which save comparison results
  in registers and require the condition?

Yes. One example is SH64.


  Any suggestions on better ways to model the MicroBlaze
  comparison operations?

  Are there some restriction on using eq/ne/lt/... the
  way I am?

Any suggestions on how to fix the problem in CSE?

There are some problems if comparisons can't be reversed. I think it's a bug in the generic code, but for any given port, it's easier - and gives better code - to make sure that all conditions can be reversed, rather than fix the generic code. I ran into this with the MXP port.

Thanks!


--
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


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