> I agree that this kind of MEM is less than ideal, but I thought:
>
> set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
>
> said that the attributes of TO_RTX will to be TO _once a pending offset-and-
> narrowing operation has been applied_. So we have:
>
> /* If we modifi
Eric Botcazou writes:
>> This is because the structure we are given is:
>>
>> (mem/v/j:SI (reg/v/f:SI 110 [ t ]) [3 t_2(D)->a+0 S1 A32])
>>
>> i.e. a 1-byte SImode reference. The strange size comes from the
>> set_mem_attributes_minus_bitpos code that was mentioned earlier
>> in the series,
> This is because the structure we are given is:
>
> (mem/v/j:SI (reg/v/f:SI 110 [ t ]) [3 t_2(D)->a+0 S1 A32])
>
> i.e. a 1-byte SImode reference. The strange size comes from the
> set_mem_attributes_minus_bitpos code that was mentioned earlier
> in the series, where we set the size based o
Ramana Radhakrishnan writes:
> On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
> wrote:
>> Ramana Radhakrishnan writes:
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .
On Wed, Nov 28, 2012 at 1:06 PM, Ramana Radhakrishnan wrote:
> On 11/28/12 10:25, Richard Biener wrote:
>>
>> On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
>> wrote:
>>>
>>> On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
>>> wrote:
Ramana Radhakrishnan writes:
>>
On 11/28/12 10:25, Richard Biener wrote:
On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
wrote:
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
wrote:
Ramana Radhakrishnan writes:
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that th
On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
wrote:
> On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
> wrote:
>> Ramana Radhakrishnan writes:
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assemb
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
wrote:
> Ramana Radhakrishnan writes:
>>> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
>>> Also tested by making sure that there were no changes in assembly
>>> output for a set of gcc .ii files. On the other hand, the -mar
Ramana Radhakrishnan writes:
>> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
>> Also tested by making sure that there were no changes in assembly
>> output for a set of gcc .ii files. On the other hand, the -march=octeon
>> output for a set of mips64-linux-gnu gcc .ii files
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .ii files. On the other hand, the -march=octeon
output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
kicking in as h
This series was inspired by Andrew's patch from September:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00126.html
and by a general frustration with the insv, extv and extzv interface.
The patches add 6 new optabs:
insvM: an M<-M register insertion
insvmisalignM: a BLK<-M m
11 matches
Mail list logo
