Thanks H-P,
That worked first time !
For a few days I had been searching the non cc0 ports for hints. Two of
the ports don't bother using the set CC side effect to avoid compares
and the others are obfuscated by the fact that they (understandably) use
custom CC modes and the reload conditions aren't obvious - even when I
inspected the .c file CCmode tests.
For example the i386 seems to use predicates and constraints of the form
<*_operand> and <m/r/i> for the reload versions of these instructions -
and I haven't been able to find definitions of these or a mention in
gcc_internals.pdf of any special meaning assigned to the <> notation.
In any case - thanks again, with this blocker cleared I can proceed with
lower stress levels :-)
Cheers, Paul.
On 17/01/12 15:19, Hans-Peter Nilsson wrote:
On Mon, 16 Jan 2012, Paul S wrote:
In the port I'm working on I have used the newer CC tracking technique (i.e.
not cc0). I have followed the directions at the top of compare-elim.c and have
the following pattern for addhi3
I'm clearly missing something... can anyone provide a hint ?
You're running into one of the grievances with cc0 conversion:
all the single_set users.
Don't expose the CC register as being set until after reload,
and in particular not from moves and adds, reload makes heavy
use of those. Make a parallel with a clobber of it instead.
Then have your pattern above with "reload_completed" instead of
"" as its condition.
(Or a shorter hint, do what other non-cc0 ports do. :)
brgds, H-P
