This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [SH] PR 51244 - Fix defects introduced in 4.8
- From: Christian Bruel <christian dot bruel at st dot com>
- To: Oleg Endo <oleg dot endo at t-online dot de>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 7 Oct 2013 10:30:11 +0200
- Subject: Re: [SH] PR 51244 - Fix defects introduced in 4.8
- Authentication-results: sourceware.org; auth=none
- References: <1380877594 dot 4778 dot 23 dot camel at yam-132-YW-E178-FTW>
Hi Oleg,
+/*
+This pass tries to optimize for example this:
+ mov.l @(4,r4),r1
+ tst r1,r1
+ movt r1
+ tst r1,r1
+ bt/s .L5
+
+into something simpler:
+ mov.l @(4,r4),r1
+ tst r1,r1
+ bf/s .L5
+
+Such sequences can be identified by looking for conditional branches and
+checking whether the ccreg is set before the conditional branch
+by testing another register for != 0, which was set by a ccreg store.
+This can be optimized by eliminating the redundant comparison and
+inverting the branch condition. There can be multiple comparisons in
+different basic blocks that all end up in the redunant test insn before the
+conditional branch. Some example RTL ...
+
Nice things to optimize the sequences when t-bit values are not recognized due to branches direction, I have 2 questions
1) I find the name "if-conversion" for this pass a little bit forced, since you don't aim to remove branches. If looks more like some kind of extension value numbering.
2) I'm wondering in which extend this case could be handled by a more global generic target value numbering to handle boolean operations. Maybe just a phasing problem as the branch directions are not yet computed in gimple-ssa, which would mean reworking in RTL ?
Many thanks,
Christian