similar to: [LLVMdev] why LoopUnswitch pass does not constant fold conditional branch and merge blocks

Hal, (and everyone who might care about post increment generation)... I have an interesting question/observation. Consider this vector loop. void vec_add_const(unsigned N, short __attribute__ ((aligned (16))) *A, short __attribute__ ((aligned (16))) val) { unsigned i,j; for (i=0; i<N; i++) { for (j=0; j<N; j++) { A[i*N+j] += val; } } } The

----- Original Message ----- > From: "Sergei Larin" <slarin at codeaurora.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, March 1, 2013 10:24:39 AM > Subject: Interesting post increment situation in DAG combiner > > Hal, (and everyone who might care about post increment generation)... Sergei, Perhaps

Hal, Here is my patch for the post inc case. I think it is symmetrically applicable to the pre-inc, but I have not tested it for that. I think you can clearly see my intent here - I simply select the "latest" candidate when multiple are available. Who else might be interested in this? Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

On Tue, Jun 1, 2010 at 5:42 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Any suggestions/ideas ? IIUC, Chris suggested something like following ... header: br i1 %x, label %then, %label endif then: ... br i1 %y, label %loop_exit, label %header, !loop_pragma !1 endif: ... br i1 %z, label %loop_exit, label %header, !loop_pragma !2 loop_exit: ret i32 1 Where !1 and !2 are the

I tried to manually assign each of 3 arrays a unique TBAA node. But it does not seem to help: alias analysis still considers arrays as may-alias, which most likely prevents the desired optimization. Below is the sample code with TBAA metadata inserted. Could you please suggest what might be wrong with it? Many thanks, - D. marcusmae at M17xR4:~/forge/llvm$ opt -time-passes -enable-tbaa -tbaa

Thanks for comments/suggestions. Yes, attaching metadata to instructions will be good choices for many cases. But for loops, attaching metadata to back-edges requires that the front end to build loops, which is an additional task for the front end. And this task is really a backend's job, not the front end's. If the only concern is that it is hard for pragma intrinsics to stay with their

Dear all, Attached notunrolled.ll is a module containing reduction kernel. What I'm trying to do is to unroll it in such way, that partial reduction on unrolled iterations would be performed on register, and then stored to memory only once. Currently llvm's unroller together with all standard optimizations produce code, which stores value to memory after every unrolled iteration, which is

Hi, ? Is there a fix for this issue??? ---> http://permalink.gmane.org/gmane.comp.audio.compression.speex.devel/2959 ? I am seeing the same thing when I compile speex in visualdsp ? These are the errors I get from using the assembly version of vq_nbest: ? ..\..\..\..\algorithms\voice\speex\src\vq.c [Error ea5004] "C:\Users\coder\AppData\Local\Temp\acc22e8547f000\acc22e8547f001.s":482

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 28, 2013 1:30:57 PM > Subject: [LLVMdev] parallel loop metadata simplification > > Hi, > > I've been working on clang codegen for #pragma ivdep and creating the >

Hello! I'v downloaded speex lib 1.1.11.1. I am trying to port speex lib to Blackfin processor. I am using VisualDSP++ 4.0. If I am compiling source codes with using floating point everything ok. When I am compiling with FIXED_POINT defined everything's ok and code works about two times faster. But when I am defining BFIN_ASM I am getting several compiling errors in Blackfin assembler

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable

If LLVM would like to support OpenMP pragma in the future, not sure if attaching metadata to instructions is still a good choice. Junjie On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges

I'd like to add a pragma support in llvm. I am thinking about using a llvm intrinsic to represent each pragma, such as llvm.pragma (metadata, ...) where metadata describes a pragma. So if an application has: #pragma p1 .. #pragma p2... for (...) The llvm IR would be llvm.pragma (metadata..) // for p1 llvm.pragma (metadata..) // for p2 llvm IR for "for

Hi Chris, Thanks. I will see what I can do for this. Junjie On Wed, May 19, 2010 at 3:45 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > >> Many compilers support per-loop pragma, such as loop unrolling (ie >> #pragma unroll=2).  Is there any LLVM project/effort going on >> in this area ? What is the expected

Tobias, I am working on one very well hidden issue with Polly loop structure. Here is a brief description. In polly::createLoop() we create something like this (topology is important): polly.start: ; preds = %polly.split_new_and_old ... <some code> br label %polly.loop_header polly.loop_after: ; preds =

Hi everyone, I'm working on some custom transformation passes that have the side-effect of significantly increasing the code size. While testing it on some larger, real-world code bases, I run into a linker error for armv7 thumb code. The particular error I get from ld64 is that "armv7 has no pc-rel bx thumb instruction." I've been able to reproduce the problem by taking a

Here some Blackfin inline assembly, mainly picked and adapted from speex. It's helps a little on my BF537 eval board. Julien -------- /** @file fixed_bfin.h @brief Fixed-point operations for the ADI BF5xx DSP family */ /* Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: -

On 10/2/19 5:12 PM, Hal Finkel wrote: On 10/1/19 12:35 AM, Serge Pavlov via llvm-dev wrote: Hi all, This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND' as well as some other

> I am trying to port speex lib to Blackfin processor. > I am using VisualDSP++ 4.0. I've never used VisualDSP++ 4.0. All the development on Blackfin has been done with gcc, which may explain some problems with the inline asm. Does VisualDSP++ support a syntax close to what gcc uses (with constraints) or more like the MS compilers. > If I am compiling source codes with using

Hi, On LLVM 5.0 (current trunk), fadd/fsub and fmul that are both marked with `contract` or `fast` can be merged to a fma instruction by the backend. I'm wondering about the exact semantic of this new flag as well as `fast` and in particular, would it be valid to do this when only the `fadd`/`fsub` (and not the `fmul`) is marked with `contract` or at least `fast`. The reasoning is that doing