On Wed, 2011-07-20 at 11:03 +0200, Richard Guenther wrote:
> I wonder if the code below triggered at all as since we expand from
> SSA we no longer see the larger trees in-place but you have to
> look them up via SSA defs using get_gimple_for_ssa_name (or the
> helper get_def_for_expr). So I expe
On Tue, 19 Jul 2011, William J. Schmidt wrote:
> I've been distracted by other things, but got back to this today...
>
> On Wed, 2011-07-06 at 16:58 +0200, Richard Guenther wrote:
> > Ah, so we still have the ARRAY_REFs here. Yeah, well - then the
> > issue boils down to get_inner_reference cano
I've been distracted by other things, but got back to this today...
On Wed, 2011-07-06 at 16:58 +0200, Richard Guenther wrote:
> Ah, so we still have the ARRAY_REFs here. Yeah, well - then the
> issue boils down to get_inner_reference canonicalizing the offset
> according to what fold-const.c imp
On Mon, 2011-07-04 at 17:30 +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 4 Jul 2011, Richard Guenther wrote:
>
> > I still do not like the implementation of yet another CSE machinery
> > given that we already have two.
>
> From reading it it really seems to be a normal block-local CSE, without
On Wed, Jul 6, 2011 at 4:28 PM, William J. Schmidt
wrote:
> On Wed, 2011-07-06 at 15:16 +0200, Richard Guenther wrote:
>> On Tue, Jul 5, 2011 at 3:59 PM, William J. Schmidt
>> wrote:
>> > (Sorry for the late response; yesterday was a holiday here.)
>> >
>> > On Mon, 2011-07-04 at 16:21 +0200, Ric
On Wed, 2011-07-06 at 15:16 +0200, Richard Guenther wrote:
> On Tue, Jul 5, 2011 at 3:59 PM, William J. Schmidt
> wrote:
> > (Sorry for the late response; yesterday was a holiday here.)
> >
> > On Mon, 2011-07-04 at 16:21 +0200, Richard Guenther wrote:
> >> On Thu, Jun 30, 2011 at 4:39 PM, William
On Tue, Jul 5, 2011 at 3:59 PM, William J. Schmidt
wrote:
> (Sorry for the late response; yesterday was a holiday here.)
>
> On Mon, 2011-07-04 at 16:21 +0200, Richard Guenther wrote:
>> On Thu, Jun 30, 2011 at 4:39 PM, William J. Schmidt
>> wrote:
>> > This is the first of three patches related
On Mon, 2011-07-04 at 17:30 +0200, Michael Matz wrote:
> From reading it it really seems to be a normal block-local CSE, without
> anything fancy. Hence, moving the pass just a little earlier (before
> pass_vrp/pass_dominator) should already provide for all optimizations. If
> not those shoul
Hi,
On Tue, 5 Jul 2011, William J. Schmidt wrote:
> Hm, I didn't think it was (currently) possible for a gimple statement to
> have a mem-ref on both RHS and LHS. Is that incorrect? This is easily
> changed if so, or if the possibility should be left open for the future.
Think aggregate copi
On Mon, 2011-07-04 at 17:30 +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 4 Jul 2011, Richard Guenther wrote:
>
> > I still do not like the implementation of yet another CSE machinery
> > given that we already have two.
>
> From reading it it really seems to be a normal block-local CSE, without
(Sorry for the late response; yesterday was a holiday here.)
On Mon, 2011-07-04 at 16:21 +0200, Richard Guenther wrote:
> On Thu, Jun 30, 2011 at 4:39 PM, William J. Schmidt
> wrote:
> > This is the first of three patches related to lowering addressing
> > expressions to MEM_REFs and TARGET_MEM_R
Hi,
On Mon, 4 Jul 2011, Richard Guenther wrote:
> I still do not like the implementation of yet another CSE machinery
> given that we already have two.
>From reading it it really seems to be a normal block-local CSE, without
anything fancy. Hence, moving the pass just a little earlier (before
On Thu, Jun 30, 2011 at 4:39 PM, William J. Schmidt
wrote:
> This is the first of three patches related to lowering addressing
> expressions to MEM_REFs and TARGET_MEM_REFs in late gimple. This patch
> contains the new pass together with supporting changes in existing
> modules. The second patch
13 matches
Mail list logo
