This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PPC failure bootstrap fix
> Jan Hubicka <jh@suse.cz> writes:
>
> > Hi,
> > the PPC failure is actually quite interesting bug. Zdenek's code does
> > (quite inovatively) create reduction of induction variables that results
> > in expression -(symbol + offset) being computed. Simplify_rtx actually
> > knows that this can be converted to (-offset)-symbol and fold_rtx
> > decides to wrap it within CONST rtx that is later put into REG_EQUAL
> > note. This note is taken by loop optimizer that verify that it is
> > immediate_operand that passes since it is LEGITIMATE_CONSTANT_P like on
> > many other targets and and finally move_movables calls emit_move_insn on
> > it that produces this expression in instruction stream. It survives
> > till final and results in instruction assembler chokes on.
> >
> > I am not sure who exactly is guilty for this failure but it looks safest to
> > prevent these constructs from being wrapped by CONST (I would say that
> > it should not be LEGITIMATE_CONSTANT_P at first places but there seems
> > to be no such checks anywhere in most backends).
> >
> > I am just testing the patch on ppc-linux. Does it seem to make sense at all?
>
> I think it really shouldn't be LEGITIMATE_CONSTANT_P. I've wondered
> before why it was safe to just stop at 'CONST'; now I know it isn't.
>
> (This is particularly interesting because I think it isn't an
> illegitimate constant on all PPC ports; I think EABI *does* have the
> right kind of relocations to be able to use it. But I know it's not
> valid on Darwin.)
>
> However, I know that requires changing every backend, so maybe this
> patch is best for now. I would suggest changing the comment, though, to
> say something like
Actually as mentioned elsewhere, the MIPS backend does refuse the
construct and it won't help him as we offload the constant to contant
pool that screws up similar way.
The very proper way is probably throw the newly produced CONST into
LEGITIMATE_CONSTANT_P and have LEGITIMATE_CONSTANT_P to refuse wrong
consts. But Richard's suggestinon about simply just accepting (plus
(symbol_ref) (const_int)) is probably the best compromise.
>
> /* NEG of PLUS could be converted into MINUS, but that causes expressions
> of the form (CONST (MINUS (CONST_INT) (SYMBOL_REF))) which many
> ports mistakenly treat as LEGITIMATE_CONSTANT_P. FIXME: those ports
> should be fixed. */
OK, I will change the comment this way before commiting if patch gets approved.
Honza