similar to: simplifycfg not happening?

You're right, it can indeed. Is there a reason -O3 doesn't do this? I had been expecting -O3 to perform full optimization. The first block still remains in any case. Is the first block needed for some purpose I'm not taking into account? On Sun, Sep 20, 2015 at 5:27 AM, Xiangyang Guo <eceguo at gmail.com> wrote: > Hi, > > if you use opt -simplifycfg, the third BB can

Hi All, I have got one domination error after running LoopVectorizer with VPlanNatviePath. Let's see simple IR snippet after loop vectorization with VPlanNatviePath. vector.body: ... br label %for.body10.preheader67 for.body10.preheader67: ; preds = %for.cond.cleanup972, %vector.body %vec.phi = phi <4 x i64> [ zeroinitializer, %for.cond.cleanup972 ], [ %8,

On Thu, 2012-01-26 at 15:12 -0600, Sebastian Pop wrote: > On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Thanks! Did you compile with any non-default flags other than -mllvm > > -vectorize? > > I used -O3 and -vectorize, no other non-default flags. If I run clang -O3 -mllvm -vectorize -S -emit-llvm -o test.ll test.c then I get no

On Tue, Jan 24, 2017 at 1:20 PM, Sanjay Patel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I started looking at the log files that you attached, and I'm confused. > The code that is supposedly causing the perf regression is created by the > loop vectorizer, right? Except the bad code is not in the "vector.body", so > is there something peculiar about

On Thu, Jan 26, 2012 at 3:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Thu, 2012-01-26 at 15:12 -0600, Sebastian Pop wrote: >> On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> > Thanks! Did you compile with any non-default flags other than -mllvm >> > -vectorize? >> >> I used -O3 and -vectorize, no other non-default

On Thu, Jan 26, 2012 at 3:41 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: >> arm-none-linux-gnueabi > > Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get Minor remark: please use -target instead of -ccc-host-triple that is now deprecated. Thanks for looking at this testcase. Sebastian -- Qualcomm

On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: > arm-none-linux-gnueabi Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get vectorization (even though I don't get vectorization when targeting x86_64). I'll let you know what I find. -Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Thanks! Did you compile with any non-default flags other than -mllvm > -vectorize? I used -O3 and -vectorize, no other non-default flags. Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

On Thu, 2012-01-26 at 14:34 -0600, Sebastian Pop wrote: > On Tue, Jan 24, 2012 at 6:41 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> enabling vectorization gets the performance down by 80% on ARM. > >> I will prepare a reduced testcase and try to find out the reason. > >> As a first shot, I would say that this comes from the vectorization of > >> code

On 12/9/13 2:13 PM, Raoux, Thomas F wrote: > > Constant propagation pass generates constant expression when undef is > used in float instructions instead of propagating the undef value. > > ; Function Attrs: nounwind > > define float @_Z1fv() #0 { > > entry: > > %add = fadd fast float undef, 2.000000e+00 > > ret float %add > > } > > Becomes:

Full_Name: Jeremiah Cohen Version: 2.9.0 OS: Windows XP Submission from: (NULL) (129.59.230.235) I believe there is a bug in the seq() function for certain values of the "from" argument. Here are examples: > seq(-.2, .1, .1) [1] -0.2 -0.1 0.0 0.1 > seq(-.3, .1, .1) [1] -3.000000e-01 -2.000000e-01 -1.000000e-01 5.551115e-17 1.000000e-01 > seq(-.4, .1, .1) [1] -0.4 -0.3

Constant propagation pass generates constant expression when undef is used in float instructions instead of propagating the undef value. ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: %add = fadd fast float undef, 2.000000e+00 ret float %add } Becomes: ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: ret float fadd (float undef, float 2.000000e+00) } Is it safe

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, December 10, 2013 2:55:36 PM > Subject: Re: [LLVMdev] Float undef value propagation > > > > On 12/9/13 2:13 PM, Raoux, Thomas F wrote: > > > > > > Constant propagation pass generates constant expression

Hi Reid, Sure. Here I attach the trimmed IR(sim_0.ll) which llc.exe takes and produces a 0 storage class symbol. The IR is fairly long but there is only 1 usage of real constant as actual argument passing to function iki_vlog_time() at line 137. The version of llc.exe is $ llc.exe --version LLVM (http://llvm.org/): LLVM version 7.0.1 DEBUG build. Default target: x86_64-pc-win32 Host

Hi, I am using the llvm codegen facility (version 7.0.1) to translate LLVM IR for different platforms. I have this error particularly in win64 platform. In my IR code I have such code snippet: %50 = call i8* @my_function(i8* %48, double 2.000000e+00, double 2.000000e+00) ... declare dllimport i8* @my_function(i8*, double, double) By passing it to llc.exe, I find following symbol is declared in

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

Hi, I have a following vector: > smallch [1] 0.0652840 0.1181300 0.0319370 0.0155700 0.0464110 0.0107850 [7] 0.0158970 0.0375900 0.0603090 0.0310300 0.0105920 0.0540580 [13] -0.0177740 0.0039393 Pretty (R 1.5.1) has problems with zero: > pretty(smallch) [1] -2.000000e-02 -3.469447e-18 2.000000e-02 4.000000e-02 6.000000e-02 [6] 8.000000e-02 1.000000e-01 1.200000e-01

I have the following output from pretty(): > pretty(c(-.1, 1)) # note 2nd element [1] -2.000000e-01 -2.775558e-17 2.000000e-01 4.000000e-01 6.000000e-01 [6] 8.000000e-01 1.000000e+00 > as.character(pretty(c(-.1, 1))) [1] "-0.2" "-2.77555756156289e-17" "0.2" [4] "0.4" "0.6"

Hi everybody, I'm trying to create a numerical data frame on which to perform PRCC. So far I have created a data frame that consists of function/vector output that displays in numerical form, but when I try and run PRCC (from epiR package) I get the following error message: "Error in solve.default(C) : Lapack routine dgesv: system is exactly singular" It appears this is because

Hi everyone, I've tried the below on R 1.9.1 and the 2004-08-30 builds of R 1.9.1 Patched and R 2.0.0 on Windows 2000, and the results are consistent. > seq(0.5, 0, by = -0.1) [1] 0.5 0.4 0.3 0.2 0.1 0.0 > seq(0.7, 0, by = -0.1) [1] 7.000000e-01 6.000000e-01 5.000000e-01 4.000000e-01 3.000000e-01 2.000000e-01 1.000000e-01 -1.110223e-16 Is this really the intended behaviour?