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
10 matches
Mail list logo
