similar to: [LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang?

On Feb 19, 2011, at 6:12 PM, Yuri wrote: > I got these warnings: > clang: warning: argument unused during compilation: '-finline-limit=50' > clang: warning: argument unused during compilation: '--param > max-inline-insns-single=50' > clang: warning: argument unused during compilation: '--param > max-inline-insns-auto=12' > clang: warning: argument

On 02/19/2011 18:29, Chris Lattner wrote: > Clang doesn't expose any equivalent Why not? Such controls are useful to tune the level of optimization. For example from my experience forcing more inlining causes code to grow due to resulting duplication but often such code is also faster. Even though cache mishits may cause it to slow down too eventually. Speed is vital for software in

Some of the run commandlines don't seem to be the *default ref* configuration. For instance, in 099.go, what's in the script is: LEVEL = ../../../.. BM=099.go ifeq ($(RUN_TYPE),test) STDIN_FILENAME = /dev/null STDOUT_FILENAME = null.out RUN_OPTIONS = 40 19 else STDIN_FILENAME = 2stone9.in STDOUT_FILENAME = 2stone9.out RUN_OPTIONS = 50 9 endif include ../../Makefile.spec95

On Thu, 21 Jul 2005, Long Fei wrote: > Does anyone know the "standard" commandline to compile and run spec95 > benchmarks ? > > I found some scripts in llvm test suite (External/SPEC/CINT95), but I am not > sure if they are the *default ref* configurations. <Some of them seem to use > smaller problem sizes.> SPEC95 was retired many years ago, so few people

On Thu, 21 Jul 2005, Long Fei wrote: > which suggests the compiling command: > gcc -DSPEC_CPU95 -O2 -o spec_go g2.c g22.c g23.c g25.c g26.c g27a.c g27b.c > g28.c g29.c g2eye.c g2jlib2.c g2jos.c g2list.c g2reas.c g2s2.c g2s3.c g2shp.c > and the running commandline: > ./spec_go 50 9 2stone9.in > < are these correct ? > I believe that we only include test/train inputs for

On Thursday 04 October 2007 04:27:47 you wrote: > Sir, you need to provide more information. What kind of errors? What > is not working? What exactly are you trying to do? What compiler are > you using? H IV0, we are using a lot of different cross-compiler (mainly based on GCC 3.4.x) When I tried to cross-compile FLAC for non-i386 platforms (such as ARM), I use use

I am trying to build FreeBSD update, STABLE branch, and buildkernel apparently snagged on ndis, which I don't want to do without. According to "man ndis", I need in kernel config options NDISAPI device ndis device wlan which I have: device wlan # 802.11 support options NDISAPI # This is in the hope of enabling Hiro USB wireless adapter device

Does anyone know the "standard" commandline to compile and run spec95 benchmarks ? I found some scripts in llvm test suite (External/SPEC/CINT95), but I am not sure if they are the *default ref* configurations. <Some of them seem to use smaller problem sizes.> SPEC95 was retired many years ago, so few people around me know how to compile and run them. I am building from

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > Hi Sid, > > This feels like it’s exposing too much of the disassembler internals > into the MCOperand representation. I’m not sure I follow why that’s > necessary. Can you elaborate a bit? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did a cvsup for RELENG_7 earlier today. # uname -a FreeBSD polo.example.org 7.1-STABLE FreeBSD 7.1-STABLE #8: Sat Apr 11 18:50:17 EDT 2009 dan@polo.example.org:/usr/obj/usr/src/sys/PHENOM amd64 No idea what went wrong here. Clues please. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g - -Wall -Wredundant-decls

--- src/gallium/drivers/nv50/nv50_program.c | 162 +++++++++++++++++++++++++------ src/gallium/drivers/nv50/nv50_program.h | 1 + 2 files changed, 132 insertions(+), 31 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_program.c b/src/gallium/drivers/nv50/nv50_program.c index 5594560..16bf2f1 100644 --- a/src/gallium/drivers/nv50/nv50_program.c +++

Hi, I can not anymore compile this version of theora. I get the following: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../i nclude -I../lib -I../lib/dec -I../lib/enc -I/usr/local/include -Wall -Wno-p arentheses -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loo ps -MT mode.lo -MD -MP -MF .deps/mode.Tpo -c -o mode.lo `test -f

On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote: > @@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs) > goto out_put; > } > > - len = text_opcode_size(tp->opcode); > + if (desc->native) > + BUG(); > + Subject: x86/alternatives: Handle native insns in text_poke_loc*() That's not really handling, is it..

I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. The reason for this is that each insn has parse bits which are not explicit operands and have differing meanings based on the insn's location within the packet and the number of insns inside the packet. In order for the disassembler

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type,

Hello, I recently installed gcc 3.2.0 next to my old gcc 2.95.3 . I understood that this should give me some performance gain. I indeed found some, but in a few cases I actually observed a considerable loss in performance. I would be interested to learn if others have similar experiences, and what the general opinion is concerning what version (and flags) to use for R! 1) gcc 3.2.0 -O3 can be

> I will do a run with --merge-strings. This should probably the the > default to match other ELF linkers. Trying --merge-strings with today's trunk I got * comment got 77 797 bytes smaller. * rodata got 9 394 257 bytes smaller. Comparing with gold, comment now has the same size and rodata is 55 021 bytes bigger. Amusingly, merging strings seems to make lld a bit faster. With

Updating the fink flac to 1.0.4, it won't compile because finds the headers of the previous version in /sw/include, because the CPPFLAGS/CFLAGS are being put before the local includes: (configure with ./configure --prefix=/sw --mandir=/sw/share/man ) gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"

On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > On 08/26/2010 13:17, Dale Johannesen wrote: >>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo