Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] llvm 2.8 fixes?"
2010 Oct 28
0
[LLVMdev] llvm 2.8 fixes?
On Oct 28, 2010, at 7:30 AM, Roland Scheidegger wrote:
> Hi,
>
> hit by a bug in llvm 2.8, I was wondering if there are any stable
> release branches? The bug is only present in the release branch, and I
> have a fix for it (see attachment). IMHO the bug is quite bad, and
> workarounds are actually ugly and generate inefficient code (couldn't
> really come up with
2012 Sep 05
0
[LLVMdev] branch on vector compare?
Am 05.09.2012 00:24, schrieb Stephen:
> Roland Scheidegger <sroland <at> vmware.com> writes:
>> This looks quite similar to something I filed a bug on (12312). Michael
>> Liao submitted fixes for this, so I think
>> if you change it to
>> %16 = fcmp ogt <4 x float> %15, %cr
>> %17 = sext <4 x i1> %16 to <4 x i32>
>> %18 =
2009 Dec 18
2
[LLVMdev] AVX Shuffles & PatLeaf Help Needed
On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote:
> Hello, David
>
> > Can you expand on this with an example? There seems to be an awful lot
> > of shuffle patterns and predicates in PPCInstrAltivec.td. What do you
> > mean by, "Canonicalize to byte ops?" Can you walk me through how that
> > works with Altivec?
>
> The basic idea is
2009 Dec 18
0
[LLVMdev] AVX Shuffles & PatLeaf Help Needed
On Dec 17, 2009, at 4:12 PM, David Greene wrote:
> On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote:
>> Hello, David
>>
>>> Can you expand on this with an example? There seems to be an awful lot
>>> of shuffle patterns and predicates in PPCInstrAltivec.td. What do you
>>> mean by, "Canonicalize to byte ops?" Can you walk me
2012 Sep 04
2
[LLVMdev] branch on vector compare?
Roland Scheidegger <sroland <at> vmware.com> writes:
> This looks quite similar to something I filed a bug on (12312). Michael
> Liao submitted fixes for this, so I think
> if you change it to
> %16 = fcmp ogt <4 x float> %15, %cr
> %17 = sext <4 x i1> %16 to <4 x i32>
> %18 = bitcast <4 x i32> %17 to i128
> %19 = icmp ne i128 %18, 0
2010 Aug 02
0
[LLVMdev] Register Allocation ERROR! Ran out of registers during register allocation!
Hi all,
My Machine environment is Clang-2.8-svn on Linux-x86. When I build
ffmpeg-0.6 using Clang, error output:
CC libavcodec/x86/mpegvideo_mmx.o
fatal error: error in backend: Ran out of registers during register
allocation!
Please check your inline asm statement for invalid constraints:
INLINEASM <es:movd %eax, %xmm3
pshuflw $$0, %xmm3, %xmm3
punpcklwd %xmm3, %xmm3
2011 Oct 17
0
[LLVMdev] LLVM Build Bot failure on llmv-x86_64-ubuntu
Looks like pinsr is not being generated on llvm-x86_64-ubuntu...
jabbey at davinci:~$ /home/jabbey/src/osuosl/buildbot/sandbox/llvm-x86_64-ubuntu/llvm-x86_64-ubuntu/llvm/Debug+Asserts/bin/llc < /home/jabbey/src/osuosl/buildbot/sandbox/llvm-x86_64-ubuntu/llvm-x86_64-ubuntu/llvm/test/CodeGen/X86/mmx-pinsrw.ll -mtriple=x86_64-linux -mattr=+mmx,+sse2
produces:
.file "<stdin>"
2010 Oct 20
0
[LLVMdev] llvm register reload/spilling around calls
On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote:
> Thanks for giving it a look!
>
> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote:
>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote:
>>
>>> So I saw that the code is doing lots of register
>>> spilling/reloading. Now I understand that due to calling
>>> conventions, there's not
2010 Oct 20
1
[LLVMdev] llvm register reload/spilling around calls
(repost with right sender address)
On 20.10.2010 18:13, Jakob Stoklund Olesen wrote:
> On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote:
>
>> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote:
>>> Look in X86InstrControl.td. The call instructions are all prefixed
>>> by:
>>>
>>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1,
2010 Oct 20
2
[LLVMdev] llvm register reload/spilling around calls
On 20.10.2010 05:00, Jakob Stoklund Olesen wrote:
> On Oct 19, 2010, at 6:37 PM, Roland Scheidegger wrote:
>
>> Thanks for giving it a look!
>>
>> On 19.10.2010 23:21, Jakob Stoklund Olesen wrote:
>>> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote:
>>>
>>>> So I saw that the code is doing lots of register
>>>>
2010 Oct 20
0
[LLVMdev] llvm register reload/spilling around calls
On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote:
> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote:
>> Look in X86InstrControl.td. The call instructions are all prefixed
>> by:
>>
>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2,
>> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
>> XMM0, XMM1, XMM2, XMM3,
2010 Oct 20
3
[LLVMdev] llvm register reload/spilling around calls
Thanks for giving it a look!
On 19.10.2010 23:21, Jakob Stoklund Olesen wrote:
> On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote:
>
>> So I saw that the code is doing lots of register
>> spilling/reloading. Now I understand that due to calling
>> conventions, there's not really a way to avoid this - I tried using
>> coldcc but apparently the backend
2017 Jun 12
3
[Mesa-dev] [RFC 0/9] Add precise/invariant semantics to TGSI
This looks like the right idea to me too. It may sound a bit weird to do
that per instruction, but d3d11 does that as well. (Some d3d versions
just have a global flag basically forbidding or allowing any such fast
math optimizations in the assembly, but I'm not actually sure everybody
honors that without tesselation...)
For 1/9:
Reviewed-by: Roland Scheidegger <sroland at vmware.com>
2020 Nov 12
2
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J <michael.j.ruhl at intel.com> wrote:
>
> >-----Original Message-----
> >From: Thomas Zimmermann <tzimmermann at suse.de>
> >Sent: Wednesday, November 11, 2020 7:08 AM
> >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; bskeggs at redhat.com;
> >airlied at linux.ie; daniel at ffwll.ch;
2017 Jun 13
1
[Mesa-dev] [RFC 0/9] Add precise/invariant semantics to TGSI
Am 13.06.2017 um 02:05 schrieb Ilia Mirkin:
> On Mon, Jun 12, 2017 at 7:57 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> FWIW surely on nv50 you could keep a single mad instruction for umad
>> (sad maybe too?). (I'm actually wondering if the hw really can't do
>> unfused float multiply+add as a single instruction but I know next to
>> nothing
2014 Nov 18
2
[Mesa-dev] [PATCH] nv50/ir: saturate FRC result to avoid completely bogus values
On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
>> For values above integer accuracy in floats, val - floor(val) might
>> actually produce a value greater than 1. For such large floats, it's
>> reasonable to be imprecise, but it's unreasonable for FRC to return a
>> value that
2020 Nov 11
2
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
Hi
Am 10.11.20 um 16:27 schrieb Ruhl, Michael J:
>
>
>> -----Original Message-----
>> From: Thomas Zimmermann <tzimmermann at suse.de>
>> Sent: Tuesday, November 10, 2020 8:37 AM
>> To: bskeggs at redhat.com; airlied at linux.ie; daniel at ffwll.ch; Ruhl, Michael J
>> <michael.j.ruhl at intel.com>; christian.koenig at amd.com
>> Cc: nouveau
2014 Nov 18
1
[Mesa-dev] [PATCH] nv50/ir: saturate FRC result to avoid completely bogus values
On 18/11/14 14:34, Roland Scheidegger wrote:
> Am 18.11.2014 um 15:05 schrieb Ilia Mirkin:
>> On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin:
>>>> For values above integer accuracy in floats, val - floor(val) might
>>>> actually produce a value greater than 1. For such
2008 Nov 14
2
performance problem with access database
Hello
I have problem with a access application, when I try to start the
application then I must wait 5 minutes ago before he started.
I do this from a WinXp Workstation to a Linux Debian Etch and samba
3.0.24 installation.
What can I do for better performance.
best regards
pat
2020 Nov 10
3
[PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type
The value of struct drm_device.ttm.type_vram can become -1 for unknown
types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
error when accessing struct nvif_mmu.type[]:
[ 18.304116] ==================================================================
[ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
[ 18.320415] Read of