search for: owhatev

Displaying 8 results from an estimated 8 matches for "owhatev".

Did you mean: whatev
2016 Sep 09
3
defaults for FP contraction [e.g. fused multiply-add]: suggestion and patch to be slightly more aggressive and to make Clang`s optimization settings closer to having the same meaning as when they are given to GCC [at least for "-O3"]
On 09/09/2016 04:31 PM, Stephen Canon wrote: > Gating this on -Owhatever is dangerous, . We should simply default to the pragma “on” state universally. Why so? [honestly asking, not arguing] My guess: b/c we don`t want programs to give different results when compiled at different "-O<...>" settings with the exception of "-Ofast". At any...
2008 Apr 18
0
[LLVMdev] llvm-ld optimization options
...the easiest to do, maybe you should start here], etc), which can then be turned into -O levels for llvm-gcc. I think you can assume that llvm-ld will be run at the same -O level as llvm-gcc. So once you have llvm-gcc sorted, the next step would be to compile all the benchmarks using llvm-gcc at -Owhatever, and llvm-link the result into a mega-monster module. This results in one module for each benchmark. Then COLE can schedule various passes on the monster modules to see what is most effective for this link-time optimization. If you used criteria X,Y and Z to determine a good set of passes for...
2008 Apr 17
3
[LLVMdev] llvm-ld optimization options
On 17 Apr 2008, at 20:39, Chris Lattner wrote: > On Thu, 17 Apr 2008, HyperQuantum wrote: >> I have been wondering why llvm-ld generates the same code with or > without the option "-O5" so I looked at its source (llvm 2.2). And > apparently, the options "-On" are accepted but never used! The program > runs a fixed set of optimization passes, unless
2012 Jul 31
1
[LLVMdev] [DragonEgg] Mysterious FRAME coming from gimple to LLVM
> According to comment in tree-nested.c, these frames should be only > introduced in case of debug or OpenMP lowering: in case of *debug*. What if you pass -O1 / -O2 / -Owhatever ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
2016 Sep 10
2
defaults for FP contraction [e.g. fused multiply-add]: suggestion and patch to be slightly more aggressive and to make Clang`s optimization settings closer to having the same meaning as when they are given to GCC [at least for "-O3"]
...lists.llvm.org> wrote: > > > > Sent from my iPhone > > On Sep 9, 2016, at 6:21 PM, Abe Skolnik <a.skolnik at samsung.com <mailto:a.skolnik at samsung.com>> wrote: > >> On 09/09/2016 04:31 PM, Stephen Canon wrote: >> >>> Gating this on -Owhatever is dangerous, . We should simply default to the pragma “on” state universally. >> >> Why so? [honestly asking, not arguing] >> >> My guess: b/c we don`t want programs to give different results when compiled at different "-O<...>" settings with the excep...
2016 Sep 09
2
defaults for FP contraction [e.g. fused multiply-add]: suggestion and patch to be slightly more aggressive and to make Clang`s optimization settings closer to having the same meaning as when they are given to GCC [at least for "-O3"]
Dear all, In the process of investigating a performance difference between Clang & GCC when both compile the same non-toolchain program while using the "same"* compiler flags, I have found something that may be worth changing in Clang, developed a patch, and confirmed that the patch has its intended effect. *: "same" in quotes b/c the essence of the problem is that the
2012 Jul 31
0
[LLVMdev] [DragonEgg] Mysterious FRAME coming from gimple to LLVM
According to comment in tree-nested.c, these frames should be only introduced in case of debug or OpenMP lowering: /* A subroutine of convert_nonlocal_reference_op. Create a local variable in the nested function with DECL_VALUE_EXPR set to reference the true variable in the parent function. This is used both for debug info and in OpenMP lowering. */ However, in this code example we
2012 Jul 31
3
[LLVMdev] [DragonEgg] Mysterious FRAME coming from gimple to LLVM
Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,