This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Patch for switch elimination (PR 54742)
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Steve Ellcey <sellcey at mips dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: james dot greenhalgh at arm dot com
- Date: Tue, 12 Aug 2014 14:40:48 -0600
- Subject: Re: RFC: Patch for switch elimination (PR 54742)
- Authentication-results: sourceware.org; auth=none
- References: <1407865606 dot 2601 dot 74 dot camel at ubuntu-sellcey> <53EA5D74 dot 9020809 at redhat dot com> <47b32a49-298e-44f0-b84b-b8f664847a67 at email dot android dot com>
On 08/12/14 14:23, Richard Biener wrote:
I think that's done when we've scrogged the loop beyond repair and want
the structures rebuilt. IIRC, that's what you recommended we do.
On August 12, 2014 8:31:16 PM CEST, Jeff Law <email@example.com> wrote:
On 08/12/14 11:46, Steve Ellcey wrote:
After talking to Jeff Law at the GCC Cauldron I have updated my
shortcut plugin pass to try and address this optimization in the
getting it added to GCC as a static pass. I fixed the code to build
the various C++ changes that have been happening in GCC but the
version I have included in this email is not working yet. When I run
on coremark I get errors like:
core_state.c: In function 'core_bench_state':
core_state.c:43:8: error: size of loop 16 should be 13, not 5
ee_u16 core_bench_state(ee_u32 blksize, ee_u8 *memblock,
core_state.c:43:8: error: bb 15 does not belong to loop 16
core_state.c:43:8: error: bb 113 does not belong to loop 16
core_state.c:43:8: error: bb 118 does not belong to loop 16
core_state.c:43:8: error: bb 117 does not belong to loop 16
Apparently there have been some changes to the loop information that
is built since GCC 4.9. I had hoped that adding a call to
after recalculating the dominance information would fix this but it
Does anyone have any ideas on how to fix up the loop information that
optimization has messed as it duplicates blocks? I tried adding a
'loop_optimizer_init (LOOPS_NORMAL)' before the fix_loop_structure
did not seem to have any affect.
Try setting the header & latch fields for the loop structure to NULL,
then call loops_set_state (LOOPS_NEED_FIXUP).
But that is _not_ the appropriate way of keeping loops preserved!