On Wed, Jan 25, 2012 at 8:20 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> I'd say open a missed optimization bug with the testcase and go ahead
>> with both patches.
>
> OK, I committed the patches yesterday and I've just opened PR 52000
> for the missed optimisation.
Btw, looking
Richard Guenther writes:
> I'd say open a missed optimization bug with the testcase and go ahead
> with both patches.
OK, I committed the patches yesterday and I've just opened PR 52000
for the missed optimisation.
Richard
On Tue, Jan 24, 2012 at 4:51 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Mon, Jan 2, 2012 at 7:54 PM, Eric Botcazou wrote:
I'd say open a missed optimization bug with the testcase and go ahead
with both patches. Let's see if Eric has some comments first though.
>>>
>
Richard Guenther writes:
> On Mon, Jan 2, 2012 at 7:54 PM, Eric Botcazou wrote:
>>> I'd say open a missed optimization bug with the testcase and go ahead
>>> with both patches. Let's see if Eric has some comments first though.
>>
>> None, but the m32c maintainer may have some.
>>
>> DJ, do you h
On Mon, Jan 2, 2012 at 7:54 PM, Eric Botcazou wrote:
>> I'd say open a missed optimization bug with the testcase and go ahead
>> with both patches. Let's see if Eric has some comments first though.
>
> None, but the m32c maintainer may have some.
>
> DJ, do you happen to know the rationale for th
> I'd say open a missed optimization bug with the testcase and go ahead
> with both patches. Let's see if Eric has some comments first though.
None, but the m32c maintainer may have some.
DJ, do you happen to know the rationale for the use of the MEM_SCALAR_P and
MEM_IN_STRUCT_P flags in m32c_i
On Mon, Jan 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
> Thanks for both replies.
>
> Richard Guenther writes:
>> On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
So in these cases fixed_scalar_and_varying_
Thanks for both replies.
Richard Guenther writes:
> On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
>>> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
>>> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
>>> a no-op on targets that don't all
On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
>> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
>> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
>> a no-op on targets that don't allow MEMs in addresses and takes on
>> suspicious semantics
> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
> a no-op on targets that don't allow MEMs in addresses and takes on
> suspicious semantics for those that do. In the former case, every
> address is
I was looking again at:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00294.html
and was comparing the RTL {true,output,anti}_dependence functions.
output_dependence and anti_dependence call fixed_scalar_and_varying_struct_p
with rtx_addr_varies_p. Many places also call true_dependence with
11 matches
Mail list logo
