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: [PATCH]: Fix PR middle-end/56382 -- Only move MODE_COMPLEX_FLOAT by parts if we can create pseudos


On Thu, Aug 29, 2013 at 2:14 AM, John David Anglin wrote:
> As expected, your patch doesn't fix the PR.

Hmm, unfortunate. The reason why I proposed it is because it would
revert to the way this code worked before http://gcc.gnu.org/r104371

The idea was to make "force" false, and let the normal back-up plans
work after failure in emit_move_via_integer.


> The bug lies in using "emit_move_complex_parts" when we can't create
> pseudos.
> There are several places in the functions that it calls where "gen_reg_rtx"
> can be
> called (e.g., "store_bit_field_using_insv").  In debugging, I found that
> fixing these
> didn't help.  In the end, it fails to find a way move the complex parts.
>
> In gcc.c-torture/compile/pr55921.c, we have two register operands so try_int
> can be true.  "emit_move_via_integer" is successful in this case.  Your
> patch might be correct.
>
> I'm not sure that can_create_pseudo_p is that big a hammer as it appears
> emit_move_complex is mainly called prior to reload.  The proposed change
> only affects the code when we can't create pseudos.  Even then, we fall back
> to emit_move_complex_parts.
>
> As you say, some other check might be more appropriate to determine
> whether a call to gen_reg_rtx might be needed in emit_move_complex_parts.
> For the PA, it would be something like "GET_MODE_BITSIZE (mode) >
> BITS_PER_WORD".
> But, we still need to check can_create_pseudo_p as we probably still want to
> use emit_move_complex_parts before reload.

I haven't tried to see what goes on in the compiler, but it feels like
your.patch just fixes a symptom. Might be just reload behaving like
reload, but it just seems to me that the problem is not that you
cannot create new pseudos at the point of the ICE. The test on whether
the optab exists is obviously not enough, you somehow need to make
sure that the move doesn't require new registers. That's something I
would expect reload to check: Can the target make the move I'm asking
for without introducing new registers...

I realize I'm not being very helpful... just thinking out loud ;-)

Ciao!
Steven


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