similar to: [LLVMdev] Build Attributes Proposal

Displaying 20 results from an estimated 70000 matches similar to: "[LLVMdev] Build Attributes Proposal"

2010 Nov 12
0
[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
2011 Jun 09
3
[LLVMdev] -fplugin-arg-dragonegg-enable-gcc-optzns status
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)
2011 Jun 09
0
[LLVMdev] -fplugin-arg-dragonegg-enable-gcc-optzns status
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
2012 Apr 03
3
[LLVMdev] pb05 results for current llvm/dragonegg
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
2010 Nov 12
1
[LLVMdev] Build Attributes Proposal
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: > *
2013 Jan 03
2
[LLVMdev] Does loop vectorizer inquire about target's SIMD capabilities?
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
2012 Apr 03
0
[LLVMdev] pb05 results for current llvm/dragonegg
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. > > >
2010 Nov 18
4
[LLVMdev] Build Attributes Proposal
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
2011 Jun 09
3
[LLVMdev] -fplugin-arg-dragonegg-enable-gcc-optzns status
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)
2010 Nov 12
5
[LLVMdev] Build Attributes Proposal
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 >>
2011 Feb 15
3
[LLVMdev] Possible LLVM or DragonEgg bug
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
2015 Mar 19
2
[LLVMdev] [cfe-dev] Controlling the LTO optimization level
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
2016 May 17
2
How to debug if LTO generate wrong code?
> 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.
2009 Sep 18
5
[LLVMdev] OT: intel darwin losing primary target status
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
2017 Aug 17
4
unable to emit vectorized code in LLVM IR
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**
2013 Jan 03
0
[LLVMdev] Does loop vectorizer inquire about target's SIMD capabilities?
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
2015 Dec 20
10
[Bug 93454] New: Can't build with LLVM/clang 3.7.0
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
2018 Jan 07
2
Relationship between clang, opt and llc
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
2019 Jul 12
2
[cfe-dev] ARM float16 intrinsic test
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],
2011 Jun 09
3
[LLVMdev] -fplugin-arg-dragonegg-enable-gcc-optzns status
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