similar to: [LLVMdev] Build Attributes Proposal

Hi Renato, > So, after long rounds to define how the build attributes are going to > be represented in IR, and after Jason has implemented build attributes > in MC, I have a proposal on how to represent this in IR. > > First, we need to distinguish between target dependent and independent > attributes. Generic things like optimization level, specific > optimizations, use of

Duncan, Below are the tabulated compile times and executable sizes. A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns C) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize Compile time (seconds) Benchmark A) stock B) gcc 4.5.4/ C)

Hi Jack, thanks for doing this. > Below are the tabulated compile times and executable sizes. > > A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize > B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns > C) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize These numbers really

On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > Hi Jack, > >> Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn >> on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. > > thanks for the numbers. How does this compare to LLVM 3.0 - were there any > regressions? The results from just before

Hi Duncan, I'm not sure you're arguing against having global build attributes (instead of just specific ones), or against the whole idea of having build attributes. I'll assume the former, as I take it that having support for ARM build attributes in LLVM is important (for compatibility, at least). On 12 November 2010 16:20, Duncan Sands <baldrick at free.fr> wrote: > *

On 3 January 2013 22:09, Nadav Rotem <nrotem at apple.com> wrote: > The loop vectorizer is now enabled by default. > I thought that was just a temporary arrangement to get the feel for it, not to actually have it on all the time (next release). Is it just for -O3 or lower too? This can cause problems, for instance on ARMv7, the default is that NEON is present, but Tegra2 doesn't

On Tue, 3 Apr 2012 08:57:51 -0400 Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > > Hi Jack, > > > >> Attached are the Polyhedron 2005 benchmark results for current > >> llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode > >> 4.3.2 and FSF gcc 4.6.3. > > >

Hi Sandeep, > Another use for build attributes would be as a means to record the > build flags selected for each translation unit so that LTO could know > how to optimize/tune the result. This use seems more important to > solve than the ARM attributes under discussion here. why not have your build system just pass the appropriate flags directly to the linker? Also, suppose some

On Thu, Jun 09, 2011 at 03:44:40PM +0200, Duncan Sands wrote: > Hi Jack, thanks for doing this. > >> Below are the tabulated compile times and executable sizes. >> >> A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize >> B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns >> C)

On Nov 12, 2010, at 8:20 AM, Duncan Sands wrote: > Hi Renato, > >> So, after long rounds to define how the build attributes are going to >> be represented in IR, and after Jason has implemented build attributes >> in MC, I have a proposal on how to represent this in IR. >> >> First, we need to distinguish between target dependent and independent >>

I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx

On Thu, Mar 19, 2015 at 11:12 AM Rafael Espíndola < rafael.espindola at gmail.com> wrote: > Having the analogous of -O0/-O1/-O2/-O3 for the LTO pipeline makes > sense I think. > > I agree that something along option number 2 is probably the best. > Some questions: > > * Should "clang -O3 foo.o -o foo" use LTO with -O3? > * Should "clang foo.o -o

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote: > I dug into this. Based on

i removed printf from loop. Now getting no error. but the IR doesnot contain vectorized code. IR Output is as follows: ; ModuleID = 'sum-vec.ll' source_filename = "sum-vec.c" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: norecurse nounwind readnone uwtable define i32 @main(i32, i8**

On Jan 3, 2013, at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 3 January 2013 22:09, Nadav Rotem <nrotem at apple.com> wrote: > The loop vectorizer is now enabled by default. > > I thought that was just a temporary arrangement to get the feel for it, not to actually have it on all the time (next release). Is it just for -O3 or lower too? The plan it

https://bugs.freedesktop.org/show_bug.cgi?id=93454 Bug ID: 93454 Summary: Can't build with LLVM/clang 3.7.0 Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

No, I meant LLD, the LLVM linker. This option for LLD is relevant for exploring different pass pipelines for link time optimization. It is essentially equivalent to the -passes flag for 'opt'. Such a flag doesn't make much sense for 'llc' because llc mostly runs backend passes, which are much more difficult to construct custom pipelines for (backend passes are often required

Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],

Current dragonegg svn has all of the -fplugin-arg-dragonegg-enable-gcc-optzns bugs for usage with -ffast-math -O3 addressed except for those related to PR2314. Using the -fno-tree-vectorize option, we can evaluate the current state of -fplugin-arg-dragonegg-enable-gcc-optzns with the Polyhedron 2005 benchmarks compared to stock dragonegg and stock gcc 4.5.4. The runtime benchmarks below show that