similar to: [LLVMdev] The question of sext instruction implementation

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 27 ++++++++++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h

previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i < gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not

previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i < gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not

I have a question about a problem I came across while I was adding support for aggregate va_arg expression in clang. The following is the example program I will use in this email. I compile the program with clang targeting mips. Note that I have not pushed all the changes I have made yet, so you will not be able to see the same results. $ clang -ccc-host-triple mipsel-unknown-linux

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 66 +++++++++++++++++++++- 1 file changed, 63 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp index dfb093c..e38a3b8 100644 ---

On Sat, May 17, 2008 at 11:34 AM, Richard Pennington <rich at pennware.com> wrote: > If I run the optimizer (opt) on this code snippet with -std-compile-opts > the optimizer hangs. > > > ; ModuleID = 'test.ubc' > target datalayout = >

Hi Hal, On Feb 4, 2013, at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Arnold Schwaighofer" <aschwaighofer at apple.com> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com>, "Hal

Hi, I know my last question was very vague (i.e. "It stopped working, what went wrong?"), so here is a little more concrete example: If I run the optimizer (opt) on this code snippet with -std-compile-opts the optimizer hangs. ; ModuleID = 'test.ubc' target datalayout =

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

On Sun, 24 Jun 2012 14:44:45 +0200 Tobias Grosser <tobias at grosser.es> wrote: > On 06/24/2012 02:42 PM, Hal Finkel wrote: > > On Sun, 24 Jun 2012 08:17:32 +0200 > > Tobias Grosser<tobias at grosser.es> wrote: > > > >> On 06/24/2012 05:42 AM, Hal Finkel wrote: > >>> On Thu, 21 Jun 2012 16:25:13 +0200 > >>> Tobias

Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise modifiers on variables inside Nouveau. This series add precise/invariant handling to TGSI, which can be then used by drivers to disable certain unsafe optimisations which may otherwise alter calculations, which depend on having the same result across shaders. This series fixes this bug in Tomb Raider and one CTS test

Hi Erick, On 2008-03-15, at 04:03, Erick Tryzelaar wrote: > I was talking to Gordon on #llvm earlier, and he challenged me with > coming up with a way to improve the ocaml binding's type safety. I > think I got an easy solution with phantom types. This could be a good step. I'm not sure I can predict all of the implications; I'd suggest you work up a proof of concept.

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi, everyone: I am very sorry to trouble you, but I need your help about my problem about ThreadLocalImpl in llvm of 2.8 version. I have compiled it in Windows xp with mingw, and have compiled skyeye(an open source project about simulator) as it uses llvm. But when I run a testcase ---- arm_hello, it came out segment fault. I used gdb.exe to trace it, it gave the following infomation: $

Hi, > I am very sorry to trouble you, but I need your help about my problem about > ThreadLocalImpl in llvm of 2.8 version. this is a very old version of LLVM, I suggest you try something newer, eg the recently released version 3.1. Best wishes, Duncan. I have compiled it in Windows xp with > mingw, and have compiled skyeye(an open source project about simulator) as it > uses

On Mon, Oct 6, 2008 at 9:30 AM, Le Anh Quang <anh_quang.le at mailbox.tu-dresden.de> wrote: > Hi, > I have a question about the "sext..to" instruction. In the document, I found > two examples: > %x = sext i8 -1 to i16 > It means: > i8 -1 = 1111 1111 --> 1111 1111 1111 1111 = i16 > how can it determinate, that the i16 value %x positive is (65535)? > And

> I'm not sure about it, when sext to results a positve/negative value? sext does signed-extension, zext does unsigned-extension. This means that zext always extends by zero bits, while with sext the additional bits are all copies of the top bit of the original value. So with sext, if it was negative in the original type when considered as a signed value, then it will be negative in the

Hi Le Anh, > how can it determinate, that the i16 value %x positive is (65535)? > And the second example: I guess you should read up on the "two's complement" format, which is how a signed value is stored in most architectures (and in these examples). In short, a sext operation takes the highest bit of the original number (the sign bit) and copies it into all the higher

On Jun 20, 2013, at 4:39 PM, Bin Tzeng <bintzeng at gmail.com> wrote: > Hi all, > > There might be a simple error in the LLVM reference manual. The example for sext instruction: > > %X = sext i8 -1 to i16 ; yields i16 :65535 > > %X should yield i16: -1, as opposed to 65535. > Here is the simple patch (also attached): These are the same value. -Chris >