Re: [PATCH 2/3] Move MEM_REF expansion to a new function

2012-03-13 Thread Richard Guenther
On Tue, 13 Mar 2012, Michael Matz wrote: > Hi, > > On Mon, 12 Mar 2012, Martin Jambor wrote: > > > OK, the following patch changes the places where I previously called the > > new function to call expand_expr with EXPAND_WRITE modifier and then > > makes sure we do not perform reads into rvalu

Re: [PATCH 2/3] Move MEM_REF expansion to a new function

2012-03-13 Thread Michael Matz
Hi, On Mon, 12 Mar 2012, Martin Jambor wrote: > OK, the following patch changes the places where I previously called the > new function to call expand_expr with EXPAND_WRITE modifier and then > makes sure we do not perform reads into rvalues in expand_expr_real_1 in > the contexts where I need

Re: [PATCH 2/3] Move MEM_REF expansion to a new function

2012-03-12 Thread Martin Jambor
Hi, On Mon, Mar 12, 2012 at 04:26:21PM +0100, Michael Matz wrote: > Hi, > > On Mon, 12 Mar 2012, Martin Jambor wrote: > > > when we expand a misaligned MEM_REF on the LHS, we must not call the > > code in expand_expr_real_1 if the subsequent patch is applied, because > > the code generates code

Re: [PATCH 2/3] Move MEM_REF expansion to a new function

2012-03-12 Thread Michael Matz
Hi, On Mon, 12 Mar 2012, Martin Jambor wrote: > when we expand a misaligned MEM_REF on the LHS, we must not call the > code in expand_expr_real_1 if the subsequent patch is applied, because > the code generates code extracting the contents of the memory to a > register, which is of course bad if

Re: [PATCH 2/3] Move MEM_REF expansion to a new function

2012-03-12 Thread Richard Guenther
On Mon, 12 Mar 2012, Martin Jambor wrote: > Hi, > > when we expand a misaligned MEM_REF on the LHS, we must not call the > code in expand_expr_real_1 if the subsequent patch is applied, because > the code generates code extracting the contents of the memory to a > register, which is of course bad