On Thu, Dec 02, 2010 at 10:54:32AM +0200, Ira Rosen wrote:
> On 1 December 2010 17:57, Daniel Jacobowitz wrote:
> > On Wed, Dec 01, 2010 at 11:16:16AM +0200, Ira Rosen wrote:
> >> The meaning of the builtin (or maybe a new tree code would be better?)
> >> is that the elements of v0, v1 and v2 are
On Tue, 30 Nov 2010, Julian Brown wrote:
> * defaults.h (VECTOR_ELEMENTS_BIG_ENDIAN): Define.
Apart from the point that new target macros should be hooks, the *very
first* thing to do with any new macro or hook is to write the .texi
documentation, which appears to be missing from this patch
On Wed, Dec 01, 2010 at 11:24:01AM +, Julian Brown wrote:
> > PowerPC also has load/store multiple, but I guess they are generated
> > in the same phase as for ARM. Maybe there are other architectures that
> > do that allocate contiguous register but earlier?
>
> I don't know about other archi
On Wed, Dec 01, 2010 at 11:16:16AM +0200, Ira Rosen wrote:
> The meaning of the builtin (or maybe a new tree code would be better?)
> is that the elements of v0, v1 and v2 are deinterleaved. I wanted the
> MEM_REFs, since we actually have three data accesses here, and
> something (builtin or tree c
On 1 December 2010 17:57, Daniel Jacobowitz wrote:
> On Wed, Dec 01, 2010 at 11:16:16AM +0200, Ira Rosen wrote:
>> The meaning of the builtin (or maybe a new tree code would be better?)
>> is that the elements of v0, v1 and v2 are deinterleaved. I wanted the
>> MEM_REFs, since we actually have thr
On Wed, 1 Dec 2010 11:16:16 +0200
Ira Rosen wrote:
> >> > v0 = MEM_REF (addr)
> >> > v1 = MEM_REF (addr + 8B)
> >> > v2 = MEM_REF (addr + 16B)
> >> > builtin (v0, v1, v2, stride=3, reg_stride=1,...)
> >
> > Would the builtin be changing the semantics of the preceding MEM_REF
> > codes? If so I do
On 30 November 2010 14:51, Julian Brown wrote:
>> >>> I think we need to somehow enhance MEM_REF, or maybe generate a
>> >>> MEM_REF for the first vector and a builtin after it.
>> >>
>> >> Yeah, keeping these things looking like memory references to most
>> >> of the compiler seems like a good p
On Tue, 30 Nov 2010 16:06:32 + (UTC)
"Joseph S. Myers" wrote:
> On Tue, 30 Nov 2010, Julian Brown wrote:
>
> > * defaults.h (VECTOR_ELEMENTS_BIG_ENDIAN): Define.
>
> Apart from the point that new target macros should be hooks, the
> *very first* thing to do with any new macro or hook is
On Wed, 17 Nov 2010 11:21:03 +
Julian Brown wrote:
> Shouldn't be more than 1-2 days, but I've been distracted by other
> bugs...
Well, this took a little longer than I thought. I think it's a good
incremental improvement though: it should improve code in a few cases
in little-endian mode, a
On Tue, 30 Nov 2010 12:25:18 +0200
Ira Rosen wrote:
> On 22 November 2010 13:46, Ira Rosen wrote:
> > On 17 November 2010 13:21, Julian Brown
> > wrote:
> >>> > We'd need to figure out what the RTL for such loads/stores
> >>> > should look like, and whether it can represent alignment
> >>> > co
On 22 November 2010 13:46, Ira Rosen wrote:
> On 17 November 2010 13:21, Julian Brown wrote:
>>> > We'd need to figure out what the RTL for such loads/stores should
>>> > look like, and whether it can represent alignment constraints, or
>>> > strides, or loads/stores of multiple vector registers
On 17 November 2010 13:21, Julian Brown wrote:
>> > We'd need to figure out what the RTL for such loads/stores should
>> > look like, and whether it can represent alignment constraints, or
>> > strides, or loads/stores of multiple vector registers simulateously.
Alignment info is kept in struct p
On Wed, 17 Nov 2010 12:16:34 +0200
Ira Rosen wrote:
> On 15 November 2010 17:33, Julian Brown
> wrote:
>
> > On Mon, 15 Nov 2010 10:12:26 +0200
> > Ira Rosen wrote:
> >
> > > Do you think now that the changes in GIMPLE and RTL (a function
> > > attached to each vector) are unnecessary?
> >
> >
On 15 November 2010 17:33, Julian Brown wrote:
> On Mon, 15 Nov 2010 10:12:26 +0200
> Ira Rosen wrote:
>
> > Hi Julian,
> >
> > On 12 November 2010 17:49, Julian Brown
> > wrote:
> > > ...
> > > The important observation is that vectors from case 1 and from
> > > cases 2/3 never interact: it's
On Mon, 15 Nov 2010 10:12:26 +0200
Ira Rosen wrote:
> Hi Julian,
>
> On 12 November 2010 17:49, Julian Brown
> wrote:
> > ...
> > The important observation is that vectors from case 1 and from
> > cases 2/3 never interact: it's quite safe for them to use different
> > element orderings, without
Hi Julian,
On 12 November 2010 17:49, Julian Brown wrote:
>
> For the first of these, I think we can get away with changing the
> vectorizer to use explicit "array" loads and stores (i.e. vldN/vstN), so
> that vector registers will hold elements in memory order -- so, all the
> contortions in th
Hi,
Here's a work-in-progress patch which fixes many execution failures
seen in big-endian mode when -mvectorize-with-neon-quad is in effect
(which is soon to be the default, if we stick to the current plan).
But, it's pretty hairy, and I'm not at all convinced it's not working
"for the wrong reas
17 matches
Mail list logo
