similar to: [LLVMdev] optimization without intrinsic instructions?

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

On 14 Sep 2015, at 06:58, Dipanjan Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Hi David, > > I think you people can help me better if I explain what I am trying to achieve. > • I have compiled gmp with LLVM 2.9 > • Linked the library statically with a stub program (gmp_demo.bc) > • Transformed the bitcode to LLVM IR: llvm-dis gmp_demo.bc -o

hi, i found the term "intrinsic" in some LLVM docs i am reading, and nowhere explains what that means. i did try to google, but nothing helpful came up. anybody please help? many thanks, Jun

hi, i have some LLVM bitcode, and trying to write a simple LLVM-based code to optimize them. i simply apply some selected passes from http://llvm.org/docs/Passes.html if i run the these optimizes once on the input LLVM bitcode, the output bitcode is optimized. but to my surprise, if i run the optimizes once more, the output bitcode is further optimized. so i have few questions: 1. why running

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

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

On Sun, Jan 6, 2013 at 4:03 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > I also encounter this issue and solved it locally by implementing this 2 > functions. > > - The linux version of StartSymbolizerSubprocess uses only POSIX function > and can be reused as is on OS X (maybe we should move it in a new > sanitizer_symbolizer_posix.cc file) > - I have a

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 // --

The IMM3/IMM5 come from here X86RecognizableInstr.cpp 943 TYPE("SSECC", TYPE_IMM3) 944: TYPE("AVXCC", TYPE_IMM5) On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> hi, >> >> some instructions

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 Thu, Sep 27, 2012 at 3:31 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, > > > On 27/09/12 08:02, Jun Koi wrote: >> >> On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: >>> >>> Hi Jun, did you tell "opt" to make use of TBAA? Also, please give >>> complete >>> IR >>> that

Hi James, Not sure if you've already found the problem but I've been looking at this issue a bit as a way to learn. What I've seen is that the wrong operand names are used for the instruction which causes the decoder emitter to fail to recognize the operands. The attached patch changes the names of the operands and adds a test for the disassembly of the instruction. I haven't

In principle, transform passes are not responsible to inspect @yyy is not aliased to @XXX. I guess "opt -basicaa -{any-transform-passes}" would help you. You may also try "opt -{any-analysis-passes} -aa-eval}" Note, opt is the tool not for users but for developers. He does not invoke unspecified passes automatically. ...Takumi 2012/8/11 Jun Koi <junkoi2004 at

I'll look into it, thanks for the report. On Thu, Jul 30, 2015 at 11:01 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Any ideas on this bug? > > Thanks. > > > On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hello, >> >> There is an issue in the latest Sparc code: while we can encode POPC, >> decode

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 everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

hi, with libvirt, is it possible to manage VMs (using virsh, for e.g) without root access? if that is possible, how can i do that? many thanks, Jun

On Sat, Aug 11, 2012 at 7:42 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > hi, > > i am trying to optimize the below code, in one of my LLVM functions: > > .... > store i32 96, i32* @XXX, align 4 ; (1) > store i32 117, i32* @yyy, align 4 ; (2) > store i32 31, i32* @XXX, align 4 ; (3) > .... > > naturally, optimize passes should remove the

On Mon, May 23, 2016 at 2:44 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hi, > > I found a mismatch between assembler & disassembler of X86: I assembled an > instruction, then disassembled the output, but the result is not the same > as the first original code: "add qword ptr [205163983024656], 1" vs " add > qword ptr [1985229328], 1" > >

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