On 15 November 2017 at 16:58, Kyrill Tkachov
wrote:
> Hi Christophe,
>
>
> On 15/11/17 15:31, Christophe Lyon wrote:
>>
>> Hi Kyrill,
>>
>>
>> On 8 November 2017 at 19:34, Kyrill Tkachov
>> wrote:
>>>
>>> On 06/06/17 14:17, James Greenhalgh wrote:
On Tue, Jun 06, 2017 at 09:40:44AM +0
Hi Christophe,
On 15/11/17 15:31, Christophe Lyon wrote:
Hi Kyrill,
On 8 November 2017 at 19:34, Kyrill Tkachov
wrote:
On 06/06/17 14:17, James Greenhalgh wrote:
On Tue, Jun 06, 2017 at 09:40:44AM +0100, Kyrill Tkachov wrote:
Hi all,
On top of the previous vec_merge simplifications [1] w
Hi Kyrill,
On 8 November 2017 at 19:34, Kyrill Tkachov
wrote:
>
> On 06/06/17 14:17, James Greenhalgh wrote:
>>
>> On Tue, Jun 06, 2017 at 09:40:44AM +0100, Kyrill Tkachov wrote:
>>>
>>> Hi all,
>>>
>>> On top of the previous vec_merge simplifications [1] we can add this
>>> pattern to perform
On 06/06/17 14:17, James Greenhalgh wrote:
On Tue, Jun 06, 2017 at 09:40:44AM +0100, Kyrill Tkachov wrote:
Hi all,
On top of the previous vec_merge simplifications [1] we can add this pattern to
perform
a store of a vec_concat of two 64-bit values in distinct registers as an STP.
This avoids
On Tue, Jun 06, 2017 at 09:40:44AM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> On top of the previous vec_merge simplifications [1] we can add this pattern
> to perform
> a store of a vec_concat of two 64-bit values in distinct registers as an STP.
> This avoids constructing such a vector explicit
Hi all,
On top of the previous vec_merge simplifications [1] we can add this pattern to
perform
a store of a vec_concat of two 64-bit values in distinct registers as an STP.
This avoids constructing such a vector explicitly in a register and storing it
as
a Q register.
This way for the code in
