On Mon, Sep 16, 2013 at 10:29:37AM +0100, James Greenhalgh wrote:
> The little endian compiler would lay memory out as:
>
>0x0 ...0x8
> | 0b | 0a | 1b | 1a | 2b | 2a | 3b | 3a |
>
> And the big endian compiler would lay out memory as:
>
>0x0 ...
On Fri, Sep 13, 2013 at 10:47:01PM +0100, Andrew Pinski wrote:
> On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
> wrote:
> > Should return '1' whatever your endianness. Throwing together a quick
> > test case, that is the case for current trunk. Do you have a testcase
> > where this goes wrong
On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
wrote:
> On Fri, Sep 13, 2013 at 07:39:08PM +0100, Andrew Pinski wrote:
>> I don't think this works for big-endian due to the way ARM decided the
>> lanes don't match up with array entry there.
>
> Hi Andrew,
>
> Certainly for the testcase I've ad
On Fri, Sep 13, 2013 at 07:39:08PM +0100, Andrew Pinski wrote:
> I don't think this works for big-endian due to the way ARM decided the
> lanes don't match up with array entry there.
Hi Andrew,
Certainly for the testcase I've added in this patch there are no issues.
Vector indexing should work c
On Fri, Sep 13, 2013 at 11:35 AM, James Greenhalgh
wrote:
>
> Hi,
>
> The vset_lane_<8,16,32,64> intrinsics are currently
> written useing assembler, but can be easily expressed
> in C.
>
> As I expect we will want to efficiently compose these intrinsics
> I've added them as macros, just as was do
Hi,
The vset_lane_<8,16,32,64> intrinsics are currently
written useing assembler, but can be easily expressed
in C.
As I expect we will want to efficiently compose these intrinsics
I've added them as macros, just as was done with the vget_lane
intrinsics.
Regression tested for aarch64-none-elf
