similar to: [LLVMdev] opt -std-compile-opts

Hi I am using the llvm 1.9 and contrary to the help page there is no option: -std-compile-opts for the command "opt". It would be nice if s.o. could list the passes which are normally done for compilation/optimization. Thanks ST PS: Is there some overview over all the passes besides the documentation in the head of the source files? Being not so fond with compilers i am somehow

All, Commits aren't taking right now because apparently Zion is out of disk space: cvs commit utils/findmisopt Checking in utils/findmisopt; /var/cvs/llvm/llvm/utils/findmisopt,v <-- findmisopt new revision: 1.9; previous revision: 1.8 done Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for llvm Insufficient disk

Reid Spencer wrote: 1) It appears that the only problem was with sending email to the llvm-commits list; any files commited to the repository should be commited. 2) The web server error log filled up /var/log, preventing the CVS commit script from sending email. The Apache error log was filled with entries like this: [client 219.140.157.109] PHP Notice: Undefined offset: 1 in

How big was that log file? If we are running close to the limit, I can just buy a new disk for zion. Other suggestions welcome. --Vikram On Nov 25, 2006, at 12:38 AM, John T. Criswell wrote: > Reid Spencer wrote: > > 1) It appears that the only problem was with sending email to the > llvm-commits list; any files commited to the repository should be > commited. > >

Is "opt" expected to honour tail calls? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Wed, Nov 11, 2009 at 8:58 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Is "opt" expected to honour tail calls? I don't believe tail call elimination is on by default. Did you try including the "-tailcallelim" option?

Resent, to the list this time instead of David (sorry for the duplicate)... On Thu, Nov 12, 2009 at 9:57 PM, David Terei <davidterei at gmail.com> wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void'

On Nov 13, 2009, at 9:07 AM, Jon Harrop wrote: > > I'll try removing the noalias and seeing if that fixes it. If so, I'll file a > bug report. Which part of LLVM would this be a bug in if things like noalias > and noreturn inhibit TCO when they shouldn't? CodeGen. I looked at noalias, and it was indeed a bug. This is now fixed on trunk in r88672. Noreturn is a

I've run into some issues with tail calls in the past, make sure you are doing the following: 1. Call should be marked with tail (obviously) 2. Next statement after tail call should be 'return void' 3. Use fast call convention for tail calls 4. Make sure the function you are calling doesn't use the 'noreturn' attribute. 5. Turn on tail calls in llc (if using the static

tail calls are only implemented for fastcall calling convention if i remeber right from my inquiries. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/e8f1dd2a/attachment.html>

On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: >> Point 4 is the one that caused me trouble for some time. >> Unfortunately >> it causes a bad interaction with the optimiser, specifically the >> 'simplifycfg' pass. What seems to happen is that since the function >> you are calling is marked with 'noreturn', the simplifycfg pass will >> then

On Friday 13 November 2009 16:26:01 Chris Lattner wrote: > On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: > >> Point 4 is the one that caused me trouble for some time. > >> Unfortunately > >> it causes a bad interaction with the optimiser, specifically the > >> 'simplifycfg' pass. What seems to happen is that since the function > >> you are

On Friday 13 November 2009 04:57:43 David Terei wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void' > 3. Use fast call convention for tail calls > 4. Make sure the function you are calling doesn't

Let's say I have 2 bytecode files, X.bc and Y.bc that I want to combine into Z.bc. Which of the following command sequences will produce more optimized code? Sequence 1: llvm-link -o tmp.bc X.bc Y.bc opt -std-compile-opts -o Z.bc tmp.bc Sequence 2: llvm-ld -O5 -o Z.bc X.bc Y.bc Without looking at details it seems like sequence 2 should produce the most optimized code. As a follow

Hi guys, I''m very new to the RoR. So please be kind to me.. I''m having problems with ferret installation in rubygems. I''m on: ruby 1.9.1p429 (2010-07-02 revision 28523) [i386-mingw32] Rails 2.3.8 and i''m running windows 7 x64 When i enter ''gem install ferret --version 0.11.6'', it returns this error: Building native extensions. This could

Hello, all. Just found this file in my e-mail atchive, hope it will be useful for somebody. ===cut=here=== Some small rules: 1) No blankspace in the paths to the top-level directories. 2) Add paths to binaries to your system PATH variable. 3) Use short paths to top-level directories. 1. Some checks & preparations. 1) Be sure, that you're using right make version: $ make

Greetings list, It's been a while since I've been able to focus on asterisk packaging but this weekend I took some time to audit and recompile packages for CentOS 4.2. You can find them here. ftp://ftp.linuxsys.com/ftp/pub/releases/CentOS-4.0 You have your choice of 1.2.1 or 1.0.10 releases. If you need zaptel modules then install this kernel as well:

Anton Korobeynikov <asl at math.spbu.ru> writes: [snip] > 2) Problem: Complains about gthr-default.h file. > Resolution: Grab gcc/gcc/gthr-win32.h file and copy it to gthr-default.h ... so --enable-threads=win32 is broken... good to know. > 3) Problem: Complains about "CL_ObjCXX" and simular ("CL_") during > compilation

On 02/25/2017 06:33 AM, Alice Wonder wrote: > On 02/25/2017 06:12 AM, Johnny Hughes wrote: >> On 02/25/2017 06:52 AM, Alice Wonder wrote: >>> https://koji.fedoraproject.org/koji/buildinfo?buildID=861692 >>> >>> The source RPM there uses >>> >>> %if 0%{?rhel} >>> # not upstreamed >>> Patch500:

On 02/25/2017 06:12 AM, Johnny Hughes wrote: > On 02/25/2017 06:52 AM, Alice Wonder wrote: >> https://koji.fedoraproject.org/koji/buildinfo?buildID=861692 >> >> The source RPM there uses >> >> %if 0%{?rhel} >> # not upstreamed >> Patch500: 0001-disable-libe-book-support.patch >> Patch501: 0001-fix-build-of-bundled-libzmf-with-boost-1.56.patch