On Mon, Jul 07, 2014 at 05:23:28PM +0100, James Greenhalgh wrote:
On Fri, Jul 04, 2014 at 03:45:10PM +0100, Marcus Shawcroft wrote:
On 24 June 2014 09:45, James Greenhalgh james.greenha...@arm.com wrote:
2014-06-20 James Greenhalgh james.greenha...@arm.com
*
On Fri, Jul 04, 2014 at 03:45:10PM +0100, Marcus Shawcroft wrote:
On 24 June 2014 09:45, James Greenhalgh james.greenha...@arm.com wrote:
2014-06-20 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_mode):
New.
On 24 June 2014 09:45, James Greenhalgh james.greenha...@arm.com wrote:
2014-06-20 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_mode): New.
(move_lo_quad_internal_be_mode): Likewise.
(move_lo_quad_mode): Convert
*ping*
Thanks,
James
On Tue, Jun 24, 2014 at 09:45:28AM +0100, James Greenhalgh wrote:
Hi,
vec_concat ( { a, b }, { c, d }) should give a new vector { a, b, c, d }.
On big-endian aarch64 targets, we have to think carefully about what this
means as we map GCC's view of endian-ness on to
Hi,
vec_concat ( { a, b }, { c, d }) should give a new vector { a, b, c, d }.
On big-endian aarch64 targets, we have to think carefully about what this
means as we map GCC's view of endian-ness on to ours. GCC (for reasons I have
yet to understand) likes to describe lane-extracts from a vector