On 11/13/2010 08:40 PM, Peter Bergner wrote:
On Sat, 2010-11-13 at 11:27 +0100, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Are you sure it's IRA and not our old friend update_equiv_regs()
which IRA
On Sat, 2010-11-13 at 11:27 +0100, Paolo Bonzini wrote:
> On 11/12/2010 03:25 PM, H.J. Lu wrote:
> > IRA may move instructions across an unspec_volatile,
>
> Do you have a testcase?
Are you sure it's IRA and not our old friend update_equiv_regs()
which IRA calls? http://gcc.gnu.org/PR41171 shows
On Sat, Nov 13, 2010 at 8:20 AM, Paolo Bonzini wrote:
> On 11/13/2010 05:10 PM, H.J. Lu wrote:
>>
>> On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
>>>
>>> On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
>>>
>>> IIUC
On 11/13/2010 05:10 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and it
would be val
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
> On 11/13/2010 04:28 PM, H.J. Lu wrote:
>>
>> VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
>
> IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and it
> would be valid, but not a noop.
>
That is b
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and
it would be valid, but not a noop.
Paolo
On Sat, Nov 13, 2010 at 6:56 AM, Paolo Bonzini wrote:
> On 11/13/2010 03:34 PM, H.J. Lu wrote:
>>
>> On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
>>>
>>> On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
>>>
>>> Do you have a testcase?
On 11/13/2010 03:34 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
x86 has
;; Clear the upper 128bits of AVX registers, equivalent to a NOP
;; if
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
> On 11/12/2010 03:25 PM, H.J. Lu wrote:
>>
>> IRA may move instructions across an unspec_volatile,
>
> Do you have a testcase?
>
x86 has
;; Clear the upper 128bits of AVX registers, equivalent to a NOP
;; if the upper 128bits are unused.
(de
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Paolo
Georg Johann Lay writes:
> What about liveness? No hard reg, pseudo, mem will live avross the
> unspec volatile. Right?
As Paul noted, this is incorrect.
> Might debug info cross unspec volatiles?
> Can the back end take the decision?
I don't understand what you mean here. It is not the case
On Thu, Nov 11, 2010 at 10:56 PM, Ian Lance Taylor wrote:
> Georg Johann Lay writes:
>
>> Suppose an backend implements some unspec_volatile (UV) and has a
>> destinct understanding of what it should be.
>>
>> If other parts of the compiler don't know exactly what to do, it's a
>> potential sourc
> What about liveness? No hard reg, pseudo, mem will live avross the
> unspec volatile. Right?
Wrong. A volatile unspec may use/change machine state not directly accessible
by gcc. Any use of or changes to the machine state modelled by gcc should be
explicit in the pattern.
i.e. if your patter
Ian Lance Taylor schrieb:
Georg Johann Lay writes:
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I schedule across the un
Georg Johann Lay writes:
> Suppose an backend implements some unspec_volatile (UV) and has a
> destinct understanding of what it should be.
>
> If other parts of the compiler don't know exactly what to do, it's a
> potential source of trouble.
>
> - "May I schedule across the unspec_volatile (UV)
Suppose an backend implements some unspec_volatile (UV) and has a
destinct understanding of what it should be.
If other parts of the compiler don't know exactly what to do, it's a
potential source of trouble.
- "May I schedule across the unspec_volatile (UV) or not?"
- "May I move the UV from
16 matches
Mail list logo
