search for: uadde

CGP also relies on the add being a simple two's complement add, since it will transform define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) { entry: %add = add i64 %b, %a %cmp = icmp ult i64 %add, %a store i1 %cmp, i1* %res_i1 store i64 %add, i64* %res_i64 ret void } to define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) { entry: %uadd.overflow = call

Hi guys, I just noticed that the LLVM has some node for signed/unsigned type( like udiv, sdiv), but why the ADD, SUB do not have the counter part sadd, uadd? best kevin

Hi, After a few distractions I'm back to work on the llvm tgsi backend. I've added clang integration and I can now compile a simple opencl program to something which sort of looks like tgsi. You can find my latest work on this here: http://cgit.freedesktop.org/~jwrdegoede/llvm http://cgit.freedesktop.org/~jwrdegoede/clang (the latter may still need to sync) I've a little test

I've run into cases where, because not all of LLVM's optimizations understand the semantics of the `llvm.$op.with.overflow` intrinsics, canonicalizing compares to `llvm.$op.with.overflow` ends up preventing optimization. For instance, running the following snippet through `opt -indvars` optimizes `%to.optimize` to `true`, but running it through `opt -instcombine -indvars` does not. ```

Hi Tom, Thanks for taking the time to answer this. On 11-01-16 18:10, Tom Stellard wrote: > On Mon, Jan 11, 2016 at 12:07:14PM +0100, Hans de Goede wrote: >> Hi, >> >> After a few distractions I'm back to work on the llvm tgsi backend. I've >> added clang integration and I can now compile a simple opencl program >> to something which sort of looks like

Hi, On 13-11-15 19:51, Tom Stellard wrote: > On Fri, Nov 13, 2015 at 02:46:52PM +0100, Hans de Goede wrote: >> Hi All, >> >> So as discussed I've started working on a TGSI backend for >> llvm to use as a way to get compute going on nouveau (and other gpu-s). >> >> I'm still learning all the ins and outs of llvm so I do not have >> much to show

So if the overflow happens for either one of the case, the return value will be implementation dependent? best kevin On Feb 17, 2015, at 2:01 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Kevin, > > On 17 February 2015 at 10:41, kewuzhang <kewu.zhang at amd.com> wrote: >> I just noticed that the LLVM has some node for signed/unsigned type( like udiv,

The Hexagon part is fixed in r364790. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> LLVM compiler development From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Joan Lluch via llvm-dev Sent: Sunday, June 30, 2019 2:04 PM To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] [hexagon][PowerPC] code regression

Hi All, I've been working on translating the tests/trivial/compute.c tests to opencl (for the buffer setup and kernel launch, I'm keeping the compute kernels in tgsi as an intermediate step). I've got the test_input_global() test working, see: https://fedorapeople.org/~jwrdegoede/compute-opencl-tgsi.c Next I wanted to convert the test_system_values() test and there I've gotten

Hi Pete, > Or do you mean that the result of an add may not even be defined? In that case would reading it be considered UB in the case where the overflow bit was set? Yeah, this is the case I'm worried about: that for example sadd.with.overflow(INT_MAX, 1) might be designed to return { poison, true } instead of giving a useful result in the first element of the struct. John

Hi Tom, Matt, I'm running into strange issues with the cos test (piglit generated_tests/cl/builtin/math/builtin-float-cos-1.0.generated.c) I have been seeing random failures (incorrect results) for some time and tried to investigate. the weird part is that the failures are not 100% reproducible, sometimes the tests pass, or partly pass (it's usually float8 and float16 subtests that

On Mon, Jan 11, 2016 at 6:07 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > After a few distractions I'm back to work on the llvm tgsi backend. I've > added clang integration and I can now compile a simple opencl program > to something which sort of looks like tgsi. > > You can find my latest work on this here: >

On Mon, Jan 11, 2016 at 12:07:14PM +0100, Hans de Goede wrote: > Hi, > > After a few distractions I'm back to work on the llvm tgsi backend. I've > added clang integration and I can now compile a simple opencl program > to something which sort of looks like tgsi. > > You can find my latest work on this here: > http://cgit.freedesktop.org/~jwrdegoede/llvm >

Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --

I suggest that LLVM needs intrinsics for add/sub with carry, e.g. declare {T, i1} @llvm.addc.T(T %a, T %b, i1 c) The current multiprecision clang intrinsics example: void foo(unsigned *x, unsigned *y, unsigned *z) { unsigned carryin = 0; unsigned carryout; z[0] = __builtin_addc(x[0], y[0], carryin, &carryout); carryin = carryout; z[1] = __builtin_addc(x[1], y[1],

Hi, On 22-02-16 13:41, Samuel Pitoiset wrote: > Hi there, > > On 02/22/2016 12:26 PM, Hans de Goede wrote: <snip> >> So back to the problem of getting OpenCL(ish) code to work again with >> the recent mesa changes. For starters I would like to get: >> >> src/gallium/tests/trivial/compute.c and then the test with mask 8, >> test_input_global() to work

Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: > > On 02/22/2016 01:46 PM, Hans de Goede wrote: >> Hi, >> >> On 22-02-16 13:41, Samuel Pitoiset wrote: >>> Hi there, >>> >>> On 02/22/2016 12:26 PM, Hans de Goede wrote: >> >> <snip> >> >>>> So back to the problem of getting OpenCL(ish) code to work again with

Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm so I do not have much to show yet. I've rebased Francisco's (curro's) latest version on top of llvm trunk, and added a commit on top to actual get it build with the latest trunk. So

Hello all again, take 2. Over in D68651 I would like to make code that attempt to saturate an value (using higher bitwidth integers) use a saturating intrinsic instead. Something like this: https://godbolt.org/z/9knBnP As can be seen, the unsigned cases are already being matched to llvm.uadd.sat intrinsics. I am hoping to extend that to the signed cases. This has numerous benefits including

I am building LLVM on OS X 10.7.5 with cmake. Under this configuration some ASan and UBSan tests are failing: $ make check-ubsan … ******************** Testing Time: 2.36s ******************** Failing Tests (11): UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp UndefinedBehaviorSanitizer :: Integer/div-zero.cpp