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]

[COMMITTED] Fix debug/60438 -- i686 stack vs fp operations


The original ICE is caused by the dwarf2cfi pass not noticing a stack
adjustment in the insn stream.  The reason for the miss is that the push/pop
was added by a post-reload splitter, which did nothing to mark the insn for
special treatment.

In the PR, Jakub and I threw around several ideas.

My first attempt, to annotate the stack adjustment so that dwarf2cfi could see
it, showed a lack of supporting infrastructure within the csa and dwarf2cfi
passes.  In order to make that path work in the short term, csa had to be crippled.

My second attempt removes ix86_force_to_memory and all uses thereof.  Thus
there are no longer any troublesome post-reload stack manipulations and
dwarf2cfi doesn't get confused.

In the case of int->float conversions, we can figure out at rtl-expand time
that we might need a bit o stack memory, and we can allocate it via
assign_386_stack_local.  This produces minimal churn in this area, though we
still get to remove some patterns that didn't have the scratch memory.

In the other cases the patterns are created by combine, and there we have no
chance to use assign_386_stack_local.  Here, I simply remove the register
alternatives, leaving the register allocator no choice but to force the value
into memory.  If I recall correctly, the old reload would barf on this (thus
the byzantine structure of the existing patterns).  But Vlad assured me that
LRA will handle this just fine.

Considering that we mostly will never choose the combined
int-convert-and-operate patterns (-Os or ancient cpu tunings only), I think
this is the best of the available options.

For stage1, it would be interesting to investigate whether we can eliminate the
assign_386_stack_local fiddly bits from int->float conversions, and simply rely
on LRA there as well.  It would certainly reduce some code duplication.
Indeed, with clever use of "enabled" perhaps we can reduce to a single pattern.

Tested on x86_64 and i686-linux.


r~

Attachment: z
Description: Text document


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