This is the mail archive of the 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: [PING^2][PATCH] PR29474: Don't canonicalize commutative operands during reload

Maxim Kuvyrkov wrote:
Maxim Kuvyrkov wrote:

I'd like to ping patch in

While testing trunk and 4.3 branch for ColdFire, I noticed several failures in gcc.c-torture testsuite, which the above patch fixes.

The patch was tested on m68k-linux-gnu and m68k-elf (both for coldfire) with no new regressions.


Without this patch current trunk ICEs in reload when compiling gcc.c-torture/execute/20060420-1.c for m68k/ColdFire. The fix is safe (as it just reduces optimization space) and it does not affect benchmarks (EEMBC and CSiBE were tested).

Is there any chance of committing this before 4.4 branches or should I ping again when stage1 has started.

Given it's a bugfix I think it's appropriate to pursue at this stage. The biggest concern is that this code (reload) can sometimes be rather fragile.

I think we want to avoid all simplifications by validate_replace_rtx during reload. I think the easiest way to accomplish this would be to make a change from

validate_replace_rtx_1 (&PATTERN (insn), from, to, insn, true);


validate_replace_rtx_1 (&PATTERN (insn), from, to, insn, (reload_in_progress ? false : true));

Within validate_replace_rtx. This would need some widespread testing across multiple targets, but I do think it's the right way to approach the problem (or as an alternative, add validate_replace_rtx_nosimplify and use that within reload1.c).


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