Re: simplify_subreg aborts bad?

[Jan Hubicka <jh at suse dot cz>]

> 
> > In this case, the code IMO hit bug in setcc pattern returning VOIDmode.
> 
> It's not a bug in the pattern.  The pattern simply specified no mode,
> as the opcode's value can be used for multiple modes.  When the
> pattern is matched, the modes are fixed by the matching pattern.
It is possible to specify VOIDmode in the machine description, but in
the real insn, the expression must have mode.  Many parts of compiler
do rely on it. Even having CONST_INTs VOIDmode is bringing common problems.
So I strongly believe that it is the bug in compiler.

You can accomplish that by having one matching pattern with VOIDmode
and other mechanizm to generate that insn in expanders, that makes it to have
mode.

Such system is used in the i386.md file for floating point operations for
instance.
> Otherwise, I'd have to duplicate all the patterns, once for each
> supported move.  I already had to do that for mov{si,cc,sf} and it was
> very painful.  Since there is no way of matching that construct in
> another pattern (except for a few key ones that also specify no mode),
> the lack of a mode in that case is harmless.  When combine tries to
> combine the patterns, it should see that the pattern is invalid, and
> choose not to combine them.  An abort seems rather harsh for a
> trial-and-error procedure.
> 
> Besides, the problem as I see it is more fundamental.  Combine is
> passing patterns to simplify_subreg without validating them (it looks
> for matching patterns *after* simpliciation, not before), and rather
> than return an error, simplify_subreg aborts.
Yes, combine is validating after transformation is done.
But the validating is basically testing, whether produced instruction is
valid instruction of the machine, not whether produced instruction
is valid RTL.

We do have number of lacking tests in the machine description, the
setcc pattern independent on mode is good example.

Honza