Joern Rennecke wrote:
Quoting Michael Eager <ea...@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 ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
