similar to: [LLVMdev] llvm 2.8 fixes?

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