Re: i386 fp jumps support bits

[Jan Hubicka <jh at suse dot cz>]

> On Sun, May 14, 2000 at 11:12:13PM +0200, Jan Hubicka wrote:
> > 1) discover that this is conditional jump (in parallel or not)
> >   I've added nontrivial_condjump_p for this. I believe that originally
> >   testing of condjump_p and condjump_in_parallel_p was necesary
> 
> Ok, I see what you're after.  I'd thought this distinction already
> handled by the appropriate parties, but I see I was mistaken.
> 
> I don't like the name "nontrivial_condjump_p", because it matches
> jumps that are trivial.  Perhaps "any_condjump_p" would be better.
I don't like it eighter, but I wasn't able to find better name.
Any_condjump_p is fine for me.
Also I think it will be better to make it not matching on unconditional jumps,
unlike our current condjump_p.
Perhaps we can introduce any_uncondjump_p as well for the HP-PA case.
> 
> > 2) See the real jump (set of pc)
> >   I am having pc_set for this and I am not aware of any other function.
> 
> This is fine.
> 
> > 3) See whether it is safe to do some basic operations, such as removing
> >   of jump w/o getting surprises.
> 
> I'm not sure the point of this one.  Perhaps I need to look again
> at the subsequent patches in context.

Basically some jumps are safe to remove, other (as branch and compare) aren't.
For removing we can test just the single_set condition, but I tought it will
be better to create test for each such use so in future when something even
more weird will come into place we will need less changes.

About changing the condition what I was after are condjumps that use
CC registers in the set as well, so changing the condtion will not only affect
the flow, but also other registers stored.

Honza
> 
> 
> r~