Re: INSN_CODE_NUMBER of INT_MAX

[Jan Hubicka <jh at suse dot cz>]

> They might finalize some computation.
Finalizing instruction IMO is the one storing the value to register.

Only exception I see is the case, where the register mentioned in REG_EQUAL
note needs to be computed later, but this does not sound as resonable solution.
> 
> > Such noop moves definitly confuse register allocator in other way - such
> > as increase priorities for the pseudo for no purpose and in a way combine
> > updates life information these also can extend register lifetime.
> > 
> > So still I would suggest to blast such noop moves REG_EQUAL note or not.
> 
> Improving one aspect by pessimizing several others doesn't seem like a good
> proposition to me.
> 
> You could try instead to
>  - find if there is a previous set where you can put the REG_EQUAL note
>    (i.e. it is in the same set of flow paths and sets the same register,
>     and there is no non-trivial REG_EQUAL note already there)
Hmm, shouldn't it be simply previous set of the register in case it is in the
same basic block?
I can teach delete_trivially_dead_insns to do this trick.
> or
>  - ignore no-op moves for the purposes of counting lifetimes and the number
>    of sets.
It may make sense to add the bypass to regclass, life-analyzis, flow, if
converison, cfg_cleanup, gcse and few other pases.
Question remain, does it make sense to worry about that.
How much gain do we get from that case?

I will try to do small experiment with keeping the noop moves with notes
consistently/removing them consistenly and come back.
> or
>  - replace them with a different notations, e.g. USEs with a REG_EQUAL note,
>    and teach all the passes up to local-alloc to use them (we already use
>    this in later passes)
This sounds more resonable. Definitly many of passes already do know how
to bypass USEs.

On the other hand, issues about keeping the USE instructions (an instructions,
not instructions) consistent are getting tricky too.
Old jump pass contained quite a lot code to move them around, that was wrong.

My approach in cleanup_cfg is to blast them off and I am nervous about it too.
Can't we come with something more robust?

In case we teach combine to work on DU/DF chains (this can be major win
anyway), we can use the same chains to lookup the note at least set.

Only exception is the exception mentioned above.  Do we want to handle it?

Honza