Hi Jeff, Steven,
I have filed a bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663
Could somebody confirm it?
I am studying this piece of codes and have spent some time on it,
I'm working on a patch and hoping could help on this issue,
Please help me review it later. Thanks.
--
Best
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 22:43, Amker.Cheng wrote:
I believe, the optimization you may be referring to is value
range propagation which does predication of values based on
predicates of conditions. GCC definitely applies VRP at the
tree stage, I am not sure
Hi,
Though conditional const information r684 - 0 is collected by
find_implicit_sets, the conditional information is recorded as local
information of bb 97, and it is not recorded in avout of bb 96, so not
in avin of bb 97 either.
To have the set in avout of bb 96 would be wrong because the
On Tue, Sep 27, 2011 at 4:19 PM, Amker.Cheng amker.ch...@gmail.com wrote:
Hi,
I ran into a case and found conditional (const) propagation is
mishandled in cprop pass.
With following insn sequence after cprop1 pass:
(note 878 877 880 96 [bb
Amker.Cheng amker.ch...@gmail.com writes:
(insn 882 881 883 96 (set (reg:CC 24 cc)
(compare:CC (reg:SI 684 [ default_num_contexts ])
(const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
(nil))
The insn49 should be propagated with conditional const from insn882
Unless there's something arch specific related to arm, insn 882 is a
compare, which won't change r684. Why do you think 0 should
propagated to r291 if r684 is not zero?
Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.
insn 882 : cc - compare
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of subtracting 0 from r684; control flow goes to
insn_49 only if (cc == 0), which implies (r684 == 0).
Then at insn_49 we have
On 09/29/11 16:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of subtracting 0 from r684; control flow goes to
insn_49 only if (cc == 0), which implies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:26, Bernd Schmidt wrote:
On 09/29/11 16:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0) jump_insn 883 : if
(cc != 0) goto insn 46 insn 49: r291 - r684
.. insn 46
cc contains the result of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 08:43, Rahul Kharche wrote:
insn 882 : cc - compare (r684, 0) jump_insn 883 : if
(cc != 0) goto insn 46 insn 49: r291 - r684 ..
insn 46
cc contains the result of subtracting 0 from r684; control flow
goes
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Bernd
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Interesting. Are the two approaches subtly different
or do they apply precisely the same predication?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:48, Rahul Kharche wrote:
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Interesting. Are
Amker.Cheng amker.ch...@gmail.com writes:
Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.
insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of
Nobody mentioned this so I might be way off but cc doesn't get (minus
(reg r684) (const_int 0)). It gets the `condition codes` modification as
a consequence of the subtraction.
Hi Paulo,
According to section comparison operations in internal:
The comparison operators may be used to compare
I believe, the optimization you may be referring to is value range
propagation which does predication of values based on predicates of
conditions. GCC definitely applies VRP at the tree stage, I am not
sure if there is an RTL pass to do the same.
There are also RTL optimizers which perform
16 matches
Mail list logo
