This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix for mainline build on mips64el-linux


On Fri, 5 May 2006, Richard Sandiford wrote:
> I might be worrying unduly, but I'm a little concerned about this patch.
> I think simplify_subreg currently only returns lvalues when given an lvalue.
> This patch appears to be the first time that we'll return an rvalue for an
> lvalue input.

Do were ever interpret paradoxical SUBREGs are lvalues?  I thought that
we use STRICT_LOW_PART as the destination of a SET in these cases.  But
I'll admit that I wouldn't be surprised if we abused paradoxical SUBREGs
somewhere, and then relied on conservation on lvalue-ness later.  Grrr.

Joseph, any chance we could go with the ultra-safe alternative of
defining an undefined_operand_subword_p and using it in expr.c's
emit_move_multi_word?  I suspect that this would help other code,
and the new predicate might be useful in other areas.

A third alternative might be to check for
    mov_optab->handles[outer].insn_code != CODE_FOR_nothing
in emit_group_store to disable this optimization for machine modes
not dirrectly supported by the hardware.  This would disable the
problematic optimization in cases where we might recurse indefinately,
but may lead to slightly inferior code.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]