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
More recent GCC caused the i8k driver to stop working, on Slackware
compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it
didn't work anymore, meaning the driver didn't load or gave total
nonsensical output.
As it turned out the asm(..) statement forgot to mention it modifies
the *regs
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/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 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 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 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 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: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 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
I re-measured the performance difference using trunk gcc and trunk
clang/llvm on a core-2 box. -fno-strict-aliasing is added to gcc
because clang/llvm's type based aliasing is not incomplete and not
enabled by default. I also added -fomit-frame-pointer to clang/llvm as
this is gcc's default. The b
On 11/13/2010 10:08 PM, Xinliang David Li wrote:
Though gcc leads LLVM in performance overrall, there are a couple of
benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
twolf (32bit), vortex (64bit). This needs to be triaged. gcc
miscompiles gcc and eon in 32bit -- is there
On Sat, Nov 13, 2010 at 2:39 PM, Paolo Bonzini wrote:
> On 11/13/2010 10:08 PM, Xinliang David Li wrote:
>>
>> Though gcc leads LLVM in performance overrall, there are a couple of
>> benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
>> twolf (32bit), vortex (64bit). This needs
Snapshot gcc-4.6-20101113 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sat, Nov 13, 2010 at 1:08 PM, Xinliang David Li wrote:
>
> Though gcc leads LLVM in performance overrall, there are a couple of
> benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
> twolf (32bit), vortex (64bit). This needs to be triaged. gcc
> miscompiles gcc and eon in
15 matches
Mail list logo