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: trouble emilinating redundant compares


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




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