On 02 Dec 12:21, Uros Bizjak wrote:
> On Tue, Dec 2, 2014 at 12:08 PM, Ilya Enkovich wrote:
>
> >> > Having stage1 close to end, may we make some decision regarding this
> >> > patch? Having a couple of working variants, may we choose and use one
> >> > of them?
> >>
> >> I propose to wait for Vl
On Tue, Dec 2, 2014 at 12:08 PM, Ilya Enkovich wrote:
>> > Having stage1 close to end, may we make some decision regarding this
>> > patch? Having a couple of working variants, may we choose and use one
>> > of them?
>>
>> I propose to wait for Vlad for an update about his plans on register
>> pr
On 05 Nov 11:00, Uros Bizjak wrote:
> On Wed, Nov 5, 2014 at 10:35 AM, Ilya Enkovich wrote:
> > Hi,
> >
> > Having stage1 close to end, may we make some decision regarding this
> > patch? Having a couple of working variants, may we choose and use one
> > of them?
>
> I propose to wait for Vlad fo
On Wed, Nov 5, 2014 at 10:35 AM, Ilya Enkovich wrote:
> Hi,
>
> Having stage1 close to end, may we make some decision regarding this
> patch? Having a couple of working variants, may we choose and use one
> of them?
I propose to wait for Vlad for an update about his plans on register
preference a
Hi,
Having stage1 close to end, may we make some decision regarding this
patch? Having a couple of working variants, may we choose and use one
of them?
Thanks,
Ilya
2014-07-15 17:38 GMT+04:00 Uros Bizjak :
> On Tue, Jul 15, 2014 at 1:01 PM, Ilya Enkovich wrote:
>> On 15 Jul 10:42, Uros Bizjak w
On Tue, Jul 15, 2014 at 1:01 PM, Ilya Enkovich wrote:
> On 15 Jul 10:42, Uros Bizjak wrote:
>> On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich
>> wrote:
>>
>> > Also fully restrict xmm8-15 does not seem right. It is just costly
>> > but not fully disallowed.
>>
>> As said earl
On 15 Jul 10:42, Uros Bizjak wrote:
> On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich
> wrote:
>
> > Also fully restrict xmm8-15 does not seem right. It is just costly
> > but not fully disallowed.
>
> As said earlier, you can try "Ya*x" as a constraint.
> >>>
> >>> I tried it
On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich wrote:
> Also fully restrict xmm8-15 does not seem right. It is just costly
> but not fully disallowed.
As said earlier, you can try "Ya*x" as a constraint.
>>>
>>> I tried it. It does not seem to affect allocation much. I do not
2014-07-14 23:58 GMT+04:00 Uros Bizjak :
> On Thu, Jul 3, 2014 at 3:38 PM, Ilya Enkovich wrote:
>> 2014-07-03 16:07 GMT+04:00 Uros Bizjak :
>>> On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich
>>> wrote:
>>>
I didn't find a nice way to fix peephole2 patterns to take register
constraints i
On Thu, Jul 3, 2014 at 3:38 PM, Ilya Enkovich wrote:
> 2014-07-03 16:07 GMT+04:00 Uros Bizjak :
>> On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote:
>>
>>> I didn't find a nice way to fix peephole2 patterns to take register
>>> constraints into account. Is there any way to do it?
>>
>> Use REX
Ping
2014-07-03 17:38 GMT+04:00 Ilya Enkovich :
> 2014-07-03 16:07 GMT+04:00 Uros Bizjak :
>> On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote:
>>
>>> I didn't find a nice way to fix peephole2 patterns to take register
>>> constraints into account. Is there any way to do it?
>>
>> Use REX_SSE_
2014-07-03 16:07 GMT+04:00 Uros Bizjak :
> On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote:
>
>> I didn't find a nice way to fix peephole2 patterns to take register
>> constraints into account. Is there any way to do it?
>
> Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.
On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich wrote:
> I didn't find a nice way to fix peephole2 patterns to take register
> constraints into account. Is there any way to do it?
Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.
> Also fully restrict xmm8-15 does not seem rig
2014-07-03 15:11 GMT+04:00 Uros Bizjak :
> On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich wrote:
>
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape
bytes in opcode). This situation happens when REX prefix is used in SSE4
instr
Hello!
>> There is already a higher priority for registers not requiring REX.
>> My patch affects cases when compiler has to use xmm8-15 and it just
>> tries to say LRA to assign them for non SSE4 instructions. I doubt it
>> would have some use for other targets than Silvermont.
>
> When it is ju
On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich wrote:
>>> Silvermont processors have penalty for instructions having 4+ bytes of
>>> prefixes (including escape
>>> bytes in opcode). This situation happens when REX prefix is used in SSE4
>>> instructions. This
>>> patch tries to avoid such sit
2014-07-03 14:56 GMT+04:00 Jakub Jelinek :
> On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote:
>> 2014-07-02 20:21 GMT+04:00 Andi Kleen :
>> > Ilya Enkovich writes:
>> >
>> >> Silvermont processors have penalty for instructions having 4+ bytes of
>> >> prefixes (including escape bytes
On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote:
> 2014-07-02 20:21 GMT+04:00 Andi Kleen :
> > Ilya Enkovich writes:
> >
> >> Silvermont processors have penalty for instructions having 4+ bytes of
> >> prefixes (including escape bytes in opcode). This situation happens
> >> when REX
2014-07-02 20:27 GMT+04:00 Jakub Jelinek :
> On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
>> Ilya Enkovich writes:
>>
>> > Silvermont processors have penalty for instructions having 4+ bytes of
>> > prefixes (including escape bytes in opcode). This situation happens
>> > when REX p
2014-07-02 20:21 GMT+04:00 Andi Kleen :
> Ilya Enkovich writes:
>
>> Silvermont processors have penalty for instructions having 4+ bytes of
>> prefixes (including escape bytes in opcode). This situation happens
>> when REX prefix is used in SSE4 instructions. This patch tries to
>> avoid such si
2014-07-02 21:03 GMT+04:00 Uros Bizjak :
> Hello!
>
>> Silvermont processors have penalty for instructions having 4+ bytes of
>> prefixes (including escape
>> bytes in opcode). This situation happens when REX prefix is used in SSE4
>> instructions. This
>> patch tries to avoid such situation by
Mike Stump writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4 instructions. This patch tries to
avoid such situation by preferring xmm0-xmm7 usage
On Jul 2, 2014, at 9:27 AM, Jakub Jelinek wrote:
> On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
>> Ilya Enkovich writes:
>>
>>> Silvermont processors have penalty for instructions having 4+ bytes of
>>> prefixes (including escape bytes in opcode). This situation happens
>>> when
Hello!
> Silvermont processors have penalty for instructions having 4+ bytes of
> prefixes (including escape
> bytes in opcode). This situation happens when REX prefix is used in SSE4
> instructions. This
> patch tries to avoid such situation by preferring xmm0-xmm7 usage over
> xmm8-xmm15 in
On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
> Ilya Enkovich writes:
>
> > Silvermont processors have penalty for instructions having 4+ bytes of
> > prefixes (including escape bytes in opcode). This situation happens
> > when REX prefix is used in SSE4 instructions. This patch t
Ilya Enkovich writes:
> Silvermont processors have penalty for instructions having 4+ bytes of
> prefixes (including escape bytes in opcode). This situation happens
> when REX prefix is used in SSE4 instructions. This patch tries to
> avoid such situation by preferring xmm0-xmm7 usage over xmm8
Hi,
Silvermont processors have penalty for instructions having 4+ bytes of prefixes
(including escape bytes in opcode). This situation happens when REX prefix is
used in SSE4 instructions. This patch tries to avoid such situation by
preferring xmm0-xmm7 usage over xmm8-xmm15 in those instruct
27 matches
Mail list logo
