On Thu, Mar 1, 2012 at 3:45 PM, Bin.Cheng wrote:
>>> Second point, as you said, PRE often get confused and moves compare
>>> EXPR far from jump statement. Could we rely on register re-materialize
>>> to handle this, or any other solution?
>>
>> Well, a simple kind of solution would be to preproces
>> Second point, as you said, PRE often get confused and moves compare
>> EXPR far from jump statement. Could we rely on register re-materialize
>> to handle this, or any other solution?
>
> Well, a simple kind of solution would be to preprocess the IL before
> redundancy elimination and separate t
On Wed, Feb 29, 2012 at 3:50 PM, Bin.Cheng wrote:
> On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
> wrote:
>> On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
>>> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
>>> wrote:
>>>
Well, with
Index: gcc/tree-ssa-pre.c
=
On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
wrote:
> On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
>> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
>> wrote:
>>
>>> Well, with
>>>
>>> Index: gcc/tree-ssa-pre.c
>>> ===
On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
wrote:
> Yes. It won't handle
>
> if (x > 1)
> ...
> tem = x > 1;
>
> or
>
> if (x > 1)
> ...
> if (x > 1)
>
> though maybe we could teach PRE to do the insertion by properly
> putting x > 1 into EXP_GEN in compute_avail (but not into AVA
On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
> wrote:
>
>> Well, with
>>
>> Index: gcc/tree-ssa-pre.c
>> ===
>> --- gcc/tree-ssa-pre.c (revision 182784)
>> +++ gcc/tree-ssa-pr
On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
wrote:
> Well, with
>
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c (revision 182784)
> +++ gcc/tree-ssa-pre.c (working copy)
> @@ -4335,16 +4335,23 @@ eliminate (void)
On Mon, Jan 2, 2012 at 2:11 PM, Amker.Cheng wrote:
> Thanks Richard,
>
> On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
> wrote:
>>
>> I've previously worked on changing GIMPLE_COND to no longer embed
>> the comparison but carry a predicate SSA_NAME only (this is effectively
>> what you do as p
Thanks Richard,
On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
wrote:
>
> I've previously worked on changing GIMPLE_COND to no longer embed
> the comparison but carry a predicate SSA_NAME only (this is effectively
> what you do as pre-processing before SCCVN). It had some non-trivial
> fallout
On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng wrote:
> Hi,
> Since SCCVN operates on SSA graph instead of the control flow graph
> for the sake of efficiency,
> it does not handle or value number the conditional expression of
> GIMPLE_COND statement.
> As a result, FRE/PRE does not simplify conditi
Hi,
Since SCCVN operates on SSA graph instead of the control flow graph
for the sake of efficiency,
it does not handle or value number the conditional expression of
GIMPLE_COND statement.
As a result, FRE/PRE does not simplify conditional expression, as
reported in bug 30997.
Since it would be com
11 matches
Mail list logo
