Displaying 8 results from an estimated 8 matches for "owhatever".
Did you mean:
whatever
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 r...
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 -O...
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 excepti...
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,