Re: [patches] Re: convert jump.c, ifcvt.c, cse.c and simplify-rtx.c to new fp conditionals

[Jan Hubicka <jh at suse dot cz>]

> Yes, you could do that, but I think it would complicate the flow graph.  
Agreed, but since these are just two equivalent branches, this should not
inhibit much of optimizations - the basic blocks remains de-facto unchanged
so only affected I can think of is ifcvt converision pass.

I am just trying to figure out way to avoid duplicating this in each backend
for instance alpha and ia-64, as richard says has only the possibly-trapping
compares and the "ordered" compare.  So the unordered compares needs to
be split to multiple branches as well.

So we have at least 3 backends having verysimilar code.
> On the ARM, it is possible to handle it with sequences like
> 
> LTGT
> 	cmf f0, f1
> 	bmi Lx
> 	bgt Lx
> 
> UNEQ
> 	cmf f0, f1
> 	bvs Lx
> 	beq Lx
> 
> The ARM md considers the two branch instructions in each of the above 
> sequences to be a single insn.  The flow-graph remains natural since we 
> don't end up jumping around the second half of the sequence.
This looks similar to trick I am doing in my new (not rewieved yet i386
code - ehm another similar bit).
In this case the conditions are fully reversable (because they are de-facto
integer branches), but the EQ/NE branches behave incorrectly on unordered,
so we have only UNEQ and LTGT branches we handle by splitting the branch
around.  It is possible to do eighter by bypassing the second jump
by UNORDERED test or making to jumps - first UNORDERED test and then the
second.

For alpha nd ia-64 this is not possible, since it do have only the "ORDERED"
test, but still I think generic code may be able to first tri version with
two branches and if it not suceed, try another one.

Another interesting oportunity, more or less machine independent is to use
conditinoal moves to construct resulting branch - thats what gcc 2.95 does.
The sequence is:
fucom
setp %al
seteq %ah
cmp al and ah and branch according it.
> 
> If the condition were to duplicated (as it would have to be for cc0 and 
> some other machines), you would end up repeating the comparison 
> instruction unnecessarily.  It might be difficult to optimize that away 
> afterwards.
Thats good point too.
On CC0 machines we may give up the generic code.

Honza