This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CSE & compare/branch template problem
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: Michael Eager <eager at eagercon dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Fri, 18 Dec 2009 19:07:58 -0500
- Subject: Re: CSE & compare/branch template problem
- References: <4B2C0DDD.1010704@eagercon.com>
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.
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.
There is a REG_EQUAL note on this insn saying that it is equal
to const zero.
I would say that is a problem; find out why the note gets there.
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.