Hi,
On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > expansion of the SSA name partition - iterate over all of them in the
> > partition and pick the lowest alignme
Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand wrote:
> > When would that be? The expansion does happen in the initial expand
> > stage, but I'm getting called from the middle-end via emit_move_insn etc.
> > which already provides me with a MEM ...
>
> Hmm. I suppose
On Tue, Jul 26, 2011 at 12:23 AM, Richard Guenther
wrote:
> Hmm. I suppose we'd need to see at the initial expand stage that the
> move is going to be handled specially. For other strict-align targets
> we end up with store/load-bit-field for unaligned accesses, so I suppose
> SPU doesn't want t
On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote:
>> > I had always understood this to reflect the simple fact that a
>> > pointer to some type must never hold a value that is not properly
>> > aligned for th
Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote:
> > I had always understood this to reflect the simple fact that a
> > pointer to some type must never hold a value that is not properly
> > aligned for that type. (Maybe this is only true on STRICT_ALIGNMENT
> > tar
On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
>> > Btw, as pseudos do not have a single def site how can the above
>> > ever be correct in the face of coalescing?
>
> I had always understood this to reflect the simple fact that a
> pointer to some type must nev
Richard Guenther wrote:
> > Btw, as pseudos do not have a single def site how can the above
> > ever be correct in the face of coalescing?
I had always understood this to reflect the simple fact that a
pointer to some type must never hold a value that is not properly
aligned for that type. (Mayb
On Mon, Jul 25, 2011 at 4:03 PM, Richard Guenther
wrote:
> On Mon, Jul 25, 2011 at 3:24 PM, Richard Guenther
> wrote:
>> On Mon, Jul 25, 2011 at 3:22 PM, Ulrich Weigand wrote:
>>> Richard Guenther wrote:
>>>
>> Well, the back-end assumes a pointer to vector type is always
>> na
On Mon, Jul 25, 2011 at 3:24 PM, Richard Guenther
wrote:
> On Mon, Jul 25, 2011 at 3:22 PM, Ulrich Weigand wrote:
>> Richard Guenther wrote:
>>
>>> >> Well, the back-end assumes a pointer to vector type is always
>>> >> naturally aligned, and therefore the data it points to can be
>>> >>>
On Mon, Jul 25, 2011 at 3:22 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>
>> >> Well, the back-end assumes a pointer to vector type is always
>> >> naturally aligned, and therefore the data it points to can be
>> >> accessed via a simple load, with no extra rotate needed.
>> >
Richard Guenther wrote:
> >> Well, the back-end assumes a pointer to vector type is always
> >> naturally aligned, and therefore the data it points to can be
> >> accessed via a simple load, with no extra rotate needed.
> >
> > I can't see any use of VECTOR_TYPE in config/spu/,
On Mon, Jul 25, 2011 at 1:15 PM, Richard Guenther
wrote:
> On Mon, Jul 25, 2011 at 1:09 PM, Ira Rosen wrote:
>> On 25 July 2011 13:57, Richard Guenther wrote:
>>> On Mon, Jul 25, 2011 at 12:52 PM, Ira Rosen wrote:
On 25 July 2011 12:39, Richard Guenther wrote:
> On Mon, Jul 25, 2011 a
On Mon, Jul 25, 2011 at 1:09 PM, Ira Rosen wrote:
> On 25 July 2011 13:57, Richard Guenther wrote:
>> On Mon, Jul 25, 2011 at 12:52 PM, Ira Rosen wrote:
>>> On 25 July 2011 12:39, Richard Guenther wrote:
On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand
wrote:
> Richard Guenther
On 25 July 2011 13:57, Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 12:52 PM, Ira Rosen wrote:
>> On 25 July 2011 12:39, Richard Guenther wrote:
>>> On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand
>>> wrote:
Richard Guenther wrote:
> On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen w
On Mon, Jul 25, 2011 at 12:52 PM, Ira Rosen wrote:
> On 25 July 2011 12:39, Richard Guenther wrote:
>> On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand wrote:
>>> Richard Guenther wrote:
On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
> On 21 July 2011 15:19, Ira Rosen wrote:
On 25 July 2011 12:39, Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand wrote:
>> Richard Guenther wrote:
>>> On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
>>> > On 21 July 2011 15:19, Ira Rosen wrote:
>>> >> I reproduced the failure. It occurs without Richard's
>>
On Mon, Jul 25, 2011 at 11:10 AM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
>> > On 21 July 2011 15:19, Ira Rosen wrote:
>> >> I reproduced the failure. It occurs without Richard's
>> >> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg0102
Richard Guenther wrote:
> On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
> > On 21 July 2011 15:19, Ira Rosen wrote:
> >> I reproduced the failure. It occurs without Richard's
> >> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01022.html) and this
> >> patches too. Obviously the vectorized loo
On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
> On 21 July 2011 15:19, Ira Rosen wrote:
>> On 20 July 2011 21:35, Ulrich Weigand wrote:
>>>
>>> The return value of foo with vectorization is 1249 instead
>>> of 1999 for some reason.
>>
>> I reproduced the failure. It occurs without Richard's
On 21 July 2011 15:19, Ira Rosen wrote:
> On 20 July 2011 21:35, Ulrich Weigand wrote:
>>
>> The return value of foo with vectorization is 1249 instead
>> of 1999 for some reason.
>
> I reproduced the failure. It occurs without Richard's
> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01022.html)
On 20 July 2011 21:35, Ulrich Weigand wrote:
> Ira Rosen wrote:
>
>> PR tree-optimization/49771
>> * gcc.dg/vect/pr49771.c: New test.
>
> This test fails (with wrong code) on spu-elf ...
>
>> +int
>> +foo (void)
>> +{
>> + int j;
>> + int i;
>> + for (i = 0; i < 1000; i++)
>> + for (j
Ira Rosen wrote:
>PR tree-optimization/49771
>* gcc.dg/vect/pr49771.c: New test.
This test fails (with wrong code) on spu-elf ...
> +int
> +foo (void)
> +{
> + int j;
> + int i;
> + for (i = 0; i < 1000; i++)
> +for (j = 0; j < 1000; j++)
> + a[j] = a[i] + 1;
> + return a[0]
On Tue, Jul 19, 2011 at 3:27 PM, Ira Rosen wrote:
> On 19 July 2011 11:50, Richard Guenther wrote:
>> On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
> ;
>>> +
>>> + if (!compare_tree_int (DR_STEP (dr), 0))
>>
>> integer_zerop (DR_STEP (dr))
>>
>
> Right. I'll change this with some other oppo
On 19 July 2011 11:50, Richard Guenther wrote:
> On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
;
>> +
>> + if (!compare_tree_int (DR_STEP (dr), 0))
>
> integer_zerop (DR_STEP (dr))
>
Right. I'll change this with some other opportunity, if that's ok.
Thanks,
Ira
On Tue, Jul 19, 2011 at 8:25 AM, Ira Rosen wrote:
> Hi,
>
> The vectorizer performs the following alias checks for data-refs with
> unknown dependence:
>
> ((store_ptr_0 + store_segment_length_0) <= load_ptr_0)
> || (load_ptr_0 + load_segment_length_0) <= store_ptr_0))
>
> where segment_length is
25 matches
Mail list logo
