search for: uadds

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

...TBAA"} And the "tgsi" looks like this: .text .file "/home/hans/foo.cl" .globl test_kern test_kern: BGNSUB MOVis TEMP1x, 0 CAL _Z13get_global_idj SHLs TEMP1y, TEMP1x, 7 LOADiis TEMP1z, [4] UADDs TEMP1y, TEMP1z, TEMP1y SHLs TEMP1x, TEMP1x, 2 LOADiis TEMP1z, [0] UADDs TEMP1x, TEMP1z, TEMP1x LOADgis TEMP1x, [TEMP1x] INEGs TEMP1x, TEMP1x LOADgis TEMP1z, [TEMP1y] UADDs TEMP1x, TEMP1x, TEMP1z STOREgis [TEMP1y], TEMP1x...

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. ```

....file "/home/hans/foo.cl" >> .globl test_kern >> test_kern: >> BGNSUB >> MOVis TEMP1x, 0 >> CAL _Z13get_global_idj >> SHLs TEMP1y, TEMP1x, 7 >> LOADiis TEMP1z, [4] >> UADDs TEMP1y, TEMP1z, TEMP1y >> SHLs TEMP1x, TEMP1x, 2 >> LOADiis TEMP1z, [0] >> UADDs TEMP1x, TEMP1z, TEMP1x >> LOADgis TEMP1x, [TEMP1x] >> INEGs TEMP1x, TEMP1x >> LOADgis TEMP1z, [TEMP1y] >> UADDs T...

...rom llvm trunk, not sure > what llvm version you are using). > > To use llc: > > llc -march=tgsi input.ll -o - > > > This will output TGSI. So after some bugfixing to fix a bunch of segfaults I get: $ bin/llc -march=tgsi ../test/CodeGen/AMDGPU/add.ll -o - # BB#0: UADDs TEMP0x, TEMP0x, 0 LOADgis TEMP1z, [TEMP1y] UADDs TEMP1y, TEMP1y, 4 LOADgis TEMP1y, [TEMP1y] UADDs TEMP1y, TEMP1z, TEMP1y STOREgis [TEMP1x], TEMP1y UADDs TEMP0x, TEMP0x, 0 RET ENDSUB and add.ll has: ;FUNC-LABEL: {{^}}test1: ;E...

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

...like this: > > .text > .file "/home/hans/foo.cl" > .globl test_kern > test_kern: > BGNSUB > MOVis TEMP1x, 0 > CAL _Z13get_global_idj > SHLs TEMP1y, TEMP1x, 7 > LOADiis TEMP1z, [4] > UADDs TEMP1y, TEMP1z, TEMP1y > SHLs TEMP1x, TEMP1x, 2 > LOADiis TEMP1z, [0] > UADDs TEMP1x, TEMP1z, TEMP1x > LOADgis TEMP1x, [TEMP1x] > INEGs TEMP1x, TEMP1x > LOADgis TEMP1z, [TEMP1y] > UADDs TEMP1x, TEMP1x, TEMP1z >...

...ike this: > > .text > .file "/home/hans/foo.cl" > .globl test_kern > test_kern: > BGNSUB > MOVis TEMP1x, 0 > CAL _Z13get_global_idj > SHLs TEMP1y, TEMP1x, 7 > LOADiis TEMP1z, [4] > UADDs TEMP1y, TEMP1z, TEMP1y > SHLs TEMP1x, TEMP1x, 2 > LOADiis TEMP1z, [0] > UADDs TEMP1x, TEMP1z, TEMP1x > LOADgis TEMP1x, [TEMP1x] > INEGs TEMP1x, TEMP1x > LOADgis TEMP1z, [TEMP1y] > UADDs TEMP1x, TEMP1x, TEMP1z >...

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