Reducing JUMPs and using conditional exec based on if_then_else

Reducing JUMPs and using conditional exec based on if_then_else

[Sami Khawam]

Hi,

I am still trying to learn the internals of gcc and 
the .md architecture description files, and I would 
be very grateful if anyone can help with the following.

I have built a CPU architecture (based on the 
OpenRISC .md files) where I would like to reduce the 
number of jump calls to a minimum and use other 
altervatives like conditional execution. I have set 
BRANCH_COST to 40 and REGISTER_MOVE_COST to 0 (so it 
can use as many MOVs at it wants) and added the 2 
insns (see below) to the .md file defining two 
conditional moves, one based on cond_exec and the 
other on if_then_else (is such thing possible?).
The problem is that the compiler cannot do any of 
the required optimizations.
Is this a limitation in ifcvt.c? Or is it me doing 
something wrong?



The insns added:

(define_insn "cond_exec_movsi"
   [(cond_exec
    (ne:CC (const_int 0) (reg:CC 32))
    (set (match_operand:SI 0 "register_operand" "=r")
	(match_operand:SI 1 "register_operand"  "r")
	  ) )]
   ""
   "CMOV %0, %1"
)

(define_insn "if_else_movsi"
   [(set (match_operand:SI 0 "register_operand" "=r")
    (if_then_else (ne:CC (const_int 0) (reg:CC 32))
     (match_operand:SI 1 "register_operand"  "r")
     (match_operand:SI 2 "register_operand"  "r")
		      ))]
   ""
   "CMOV_ELSE %0, %1, %2"
)



Thanks for your help,

Sami Khawam

Re: Reducing JUMPs and using conditional exec based on if_then_else

[Hans-Peter Nilsson]

On Sun, 28 Nov 2004, Sami Khawam wrote:
> I have built a CPU architecture (based on the
> OpenRISC .md files)

Which isn't in the official GCC sources.  There's a hint
there...

> where I would like to reduce the
> number of jump calls to a minimum and use other
> altervatives like conditional execution. I have set
> BRANCH_COST to 40 and REGISTER_MOVE_COST to 0 (so it
> can use as many MOVs at it wants) and added the 2
> insns (see below) to the .md file defining two
> conditional moves, one based on cond_exec and the
> other on if_then_else (is such thing possible?).
> The problem is that the compiler cannot do any of
> the required optimizations.
> Is this a limitation in ifcvt.c? Or is it me doing
> something wrong?

It seems what you want is the standard pattern movXcc (where X
is the mode of the data you want to move), so you need to name
your pattern movsicc.  Did you miss this in the documentation?
I can see it.  If the wording is bad, please help with patches.
When you look at existing targets (another hint) this is usually
implemented as a define_expand.  See for example mmix.md.

brgds, H-P

Re: Reducing JUMPs and using conditional exec based on if_then_else

[Sami Khawam]

Thanks a lot Hans-Peter for the info; indeed the 
documentation explains it quite well, however it 
does not explain well how to deal with the expansion 
on CPU that dont have a cc0.

Anyway, tried it with movsicc (without splitting it) 
and it works. However, there is a small problem.

The code is able to convert something like
         t1 = a+b;
         t2 = 8 - b;

         if (a <= 5)
             i = t1 ;
         else
             i = t2;

to make it use the movsicc insn, but if it is 
written as:
         if (a <= 5)
             i = a + b;
         else
             i = 8 - b;

the compiler does not recognise the optimisation and 
keeps using a jump, even though I set the 
BRANCH_COST to 999 and REGISTER_MOVE_COST to 0.

Am I missing something that would enable this 
optimisation?

Many thanks,

Sami Khawam

Re: Reducing JUMPs and using conditional exec

[Sami Khawam]

Hi Adrian,

Thanks for the reply.

Acctually, the architecture I have only supports 
conditional moves, and no other conditional operation.
I tried defining the conditional move (see end of 
msg) along side a definitions of 'cbranchsi4' and 
'movesicc', however, it only works for simple 
conditional copying that dont require the 
computation of an intermediate value (see me 
previous email). I also tried, as you suggest, using 
'define_cond_exec' and 'predicable' to expand all 
the insn with cond_exec, but that didn't help.

The problem seems as if the compiler thinks that it 
is always better to use jumps than using excessive 
moves, which is not really the case in the 
architecture I have.





(define_insn "*my_cond_mov"
   [(cond_exec
    (match_operator 0 "comparison_operator"
[(match_operand:SI 1 "register_operand" "r")
  (match_operand:SI 2 "register_operand" "r")])
   (set (match_operand:SI 3 "register_operand" "=r")
(match_operand:SI 4 "general_operand"  "rmIKi")
	 ) )]
   ""
   "COMP_MOV %C0,%1, %2, %3, %4, %3"
)


Regards,

Sami Khawam




Adrian Strätling wrote:
> Sami Khawam wrote::
> 
>>
>>
>> Thanks a lot Hans-Peter for the info; indeed the documentation 
>> explains it quite well, however it does not explain well how to deal 
>> with the expansion on CPU that dont have a cc0.
> 
> 
> I wrote my diploma thesis about a processor that can execute any 
> operation conditional. It can use several condition registers for that 
> purpose. The key idea is the 'define_cond_exec' pattern combined with 
> the 'predicable' attribute. You may want to look at the solution to my 
> problem at 
> http://rtg.informatik.tu-chemnitz.de/obj.php/da-astr.pdf?id=162&mime=application%2Fpdf 
> 
> 
> hth,
> Adrian Strätling