"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> And we don't want to arm our detractors with bad SPEC numbers. I can just
> imagine the FUD spreading... we've got to fix it or backout.
For me as a gcc user miscompilations are far worse than bad SPEC numbers.
I never run SPEC, but if my programs
Roman Zippel <[EMAIL PROTECTED]> writes:
> The new subreg lowering pass seems to generate a bit worse code on m68k
> than before, let's take simple example:
FWIW
I see the opposite on i386: I have a function that strangely ran
slower with -fomit-frame-pointer than without on 4.1. With a 4.3
s
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> This is the project proposal that I am planning to submit to Google
> Summer of Code 2007. It is based on previous work of Jeffrey Laws,
> Diego Novillo and others. I hope someone will find it interesting and
> perhaps would like to act as mentor
Andrew MacLeod <[EMAIL PROTECTED]> writes:
>
> Do you mean implement this as a single linked list and then to find the
> previous instruction, start at the beginning of the block and traverse
> forward? Back in the early days of tree-ssa we did such a thing with the
> tree iterators. It was too sl
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2007 at 11:13:44AM -0700, Ian Lance Taylor wrote:
> > The obvious way to make the proposed tuples position independent would
> > be to use array offsets rather than pointers.
>
> I suggest instead, if we want something like this, tha
On Wed, Apr 11, 2007 at 04:55:02PM +0100, Dave Korn wrote:
> On 11 April 2007 12:53, Andi Kleen wrote:
>
> > Richard Henderson <[EMAIL PROTECTED]> writes:
> >
> >> On Tue, Apr 10, 2007 at 11:13:44AM -0700, Ian Lance Taylor wrote:
> >>> The obv
Dale Johannesen <[EMAIL PROTECTED]> writes:
> I've currently got the job of implementing pragma(s) to change
> optimization level in the middle of a file. This has come up a few
> times before,
Would it be possible to make it a function attribute? I would
really like to have
void __attribute__(
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
> A user! Can you explain why?
The x86-64 2.4 linux kernel uses it
> Thanks. I was under the impression that 2.4 doesn't build with GCC
> HEAD, anyway - I saw some patches pile up and not get applied.
AFAIK some gcc 4.0 patches went in. I assume it will build eventually
at least once 4.0 is released.
> Does 2.6 still use the option?
No.
However the change nee
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Splitting up libgcj.so probably makes sense even for the Linux distro
> case (the one I am most concerned with at the moment), just so that
> apps that don't use AWT or Swing don't really pay for it. The
Hmm? Unless you initialize AWT/swing in all progra
Karel Gardas <[EMAIL PROTECTED]> writes:
> I've thought that L1 and L2 DTLB misses are the most important for the
> overall performance or performance degradation, if not please correct
> me since this is my first attempt to measure and interpret such data.
TLB is just for caching the translation
Mike Stump <[EMAIL PROTECTED]> writes:
> Any objections to adding Visual C++ style inline asms?
Doesn't that need support to parse assembly? (= essentially
a builtin assembler). How else would the compiler
know what registers are clobbered and where to put input/output
variables?
All compilers i
"Steven J. Hill" <[EMAIL PROTECTED]> writes:
> I have discovered what appears to be an optimization bug with '-Os'
> in GCC-4.1.0 for the MIPS architecture. It appears that functions
> which are declared as 'inline' are being ignored and instead turned
> into to function calls which is breaking th
Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> I'm not sure what you're saying. The limitation on command-line
> length can be in either the shell, or the OS. In Windows 2000, the
> limitation comes primarily from the Windows command shell.
Linux has a similar limit which comes from the OS (norm
On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
> Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
> i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
> UltraSparc, ...).
Yes you're right. Somehow I only remembered the number 32.
Anyways, it's still
Richard Henderson <[EMAIL PROTECTED]> writes:
> main:
> leal4(%esp), %ecx # create argument pointer
> andl$-16, %esp# align stack
> pushl -4(%ecx) # copy return address
This will misaligned the call/ret stack in the CPU, leading t
Robert Dewar <[EMAIL PROTECTED]> writes:
>
> I must say I am a bit surprised that gcc never takes advantage
> of the fact that inc and dec do not destroy the carry flag, this
> is quite significant for some loops.
A lot of this old wisdom is no longer true.
inc and dec are to be generally avoide
Ron McCall <[EMAIL PROTECTED]> writes:
> On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote:
> > Is there a way to get some type of debugging output that tells me
> > what line of C code produced what lines of asm code?
>
> How about $TARGET-objdump --disassemble --source?
That's tota
Ondřej Bílka writes:
> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. When I asked about be
Ondřej Bílka writes:
>
> On ivy bridge I got that Using rep stosq for memset(x,0,4096) is 20%
> slower than libcall for L1 cache resident data while 50% faster for data
> outside cache. How do you teach compiler that?
It would be in theory possible with autofdo. Profile with a cache miss
event. C
> > As I am bit concerned with performance why require nops there? Add a
> > byte count number >= requested thats boundary of next instruction. When
> > lifepatching for return you need to copy this followed by jump back to next
> > instruction. Then gcc could fill that with instructions that don't
Jason Merrill writes:
>
> You don't even need to worry about the hash code, you can use the
> timestamp by itself. Given the timestamp,
>
> git log -1 --until 1440153969
Consider tree merges. There's no guarantee a time stamp maps to
monotonically increasing commit numbers.
But I don't really
Martin Liška writes:
>
> I'm also surprised about it :) Let's start without invention of a new flag,
> I'll work on that.
You definitely need a new flag: atomic or per thread instrumentation
will almost certainly have significant overhead (either at run time
or in memory). Just making an existin
Mike Izbicki writes:
> Right, but I've never taken a look at the gcc codebase. Where would I
> start looking for the relevant files? Is there a general introduction
> to the codebase anywhere that I should start with?
grep for all the flags set in the two functions below (from gcc/opts.c),
wit
Paulo Matos writes:
>
> That's what I understood as well. Someone mentioned to leave the patch
> level number to the distros to use which sounded like a good idea.
Sounds like a bad idea, as then there would be non unique gcc versions.
redhat gcc 5.0.2 potentially being completely different from
Jan Hubicka writes:
Nice patch.
> The implementation is pretty straighforward except for -fbypass-asm requiring
> one existing OBJ file to fetch target's file attributes from. This is
> definitly not optimal, but libiberty currently can't build output files from
> scratch. As Ian suggested, I p
Robert Stevenson <9goli...@gmail.com> writes:
> I am planning to begin a project to explore the space of tuning gcc
> internals in an effort to increase performance. I am wondering if
> anyone can point to me any parameterizations, heuristics, or
> priorities functions within gcc that can be tuned
Is there any specific reason why none of the graphite loop optimizations
(loop-block, loop-interchange, loop-strip-mine, loop-jam)
are enabled with -O3 or -Ofast?
I assume doing so would make them much more widely used.
Perhaps would be something to consider for 5.0?
-Andi
Matt Godbolt writes:
>
> I'll happily file a bug if necessary but I'm not clear in what phase
> the optimization opportunity has been missed.
Please file a bug with a test case. No need to worry about the phase
too much initially, just fill in a reasonable component.
-Andi
Didier Garcin writes:
> many OS hobbyist developpers would be pleased GCC implements the
> interrupt or interrupt_handler attribute for Intel architecture.
>
> Would it be so difficult to implement for this architecture ?
There are lots of different ways to implement interrupts on x86
(e.g. what
Ilya Palachev writes:
>
> But why create_gcov does not inform about that (no branch events were
> found)? It creates empty gcov file and says nothing :(
>
> Moreover, in the mentioned README it is said that perf should also be
> executed with option -e BR_INST_RETIRED:TAKEN.
Standard perf doesn't
> > BTW the biggest problem with autofdo currently is that it is
> > quite bitrotten and supports only several years old perf.
> > So all of this above will only work with old distributions,
> > unless you compile an old perf utility first.
>
> Do you mean newer perf does not support LBR (-b) any
On Tue, Apr 21, 2015 at 10:27:49AM -0700, Dehao Chen wrote:
> In that case, we should get quipper fixed upstream to accommodate new
> format. (Maybe they already fixed it, I will do a batch sync to make
> quipper up-to-date).
>From a quick look at
http://git.chromium.org/gitweb/?p=chromiumos/pla
On Tue, Apr 21, 2015 at 01:52:18PM -0700, Dehao Chen wrote:
> Andi,
>
> Thanks for the patches. Turns out that the first 3 patches are already
> in, the correct upstream quipper repository is:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/master/chromiumos-wide-profiling/
>
> The
On Wed, Apr 22, 2015 at 05:15:47AM +0200, Andi Kleen wrote:
> On Tue, Apr 21, 2015 at 01:52:18PM -0700, Dehao Chen wrote:
> > Andi,
> >
> > Thanks for the patches. Turns out that the first 3 patches are already
> > in, the correct upstream quipper re
> Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount
> options to other architectures, we should implement a target-independent
> option -fprolog-pad=N, which will generate a pad of N nops at the beginning
> of each function and add a section entry describing the pad sim
> Rather than just a sequence of NOP's, should the first NOP be a
> unconditional branch to the beginning of the real function? I don't
> know if this applies to AArch64 cpus, but I believe some cpus can handle
> such branches already in the decode unit, thus avoiding any extra cycles
> for skippi
Indu Bhagat writes:
> Proposal to add diagnostics to know which functions were not run in the
> training run in FDO.
Don't you think the warning will be very noisy? I assume most programs
have a lot of cold error handling functions etc. that are never executed
in a normal execution.
Like how do
>
> Regarding the function level detail being too noisy : I sort of agree with
> that
> comment. But I am of the opinion that I would rather leave it to the user to
> infer the profile quality as per the application characteristics.
Makes sense I guess. But I would keep the drill down as opt-
sameeran joshi writes:
> Hi,
> I have a random C program as a test case, for which I need to do
> source code coverage on gcc.
> I have used the gcov tool and further the lcov tool. The percentage of
> source code coverage which I get after using gcov, Is that the final %
> which I need to do gcc
Radu Ometita writes:
> Hello everyone!
>
> We are working on writing a paper about testing the reliability of C
> compilers by using Csmith (a random C99 program generator).
>
> A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of
> those have been marked by developers as P1
> (
Wojciech Muła writes:
>
> The main concern is if it's a proper approach? Seems that to match
> other logic functions, like "a & b | c", a separate pattern is required.
> Since an argument can be either negated or not, and we can use three
> logic ops (or, and, xor) there would be 72 patterns. So
On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
> 1) check_structured_block_conditions()
> checks for the conditions related to a structured block
> 1.no returns in block
returns should be allowed inside statement expressions.
> 2.no gotos
> 3.no breaks
> a
sameeran joshi writes:
> On 3/24/19, Andi Kleen wrote:
>> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>>> 1) check_structured_block_conditions()
>>> checks for the conditions related to a structured block
>>> 1.no returns in b
> That is a correct diagnostics.
>
> See Canonical loop form.
>
> test-expr One of the following:
> var relational-op b
> b relational-op var
>
> ( var relational-op b )
> is neither of those.
Still seems strange to fail for some meaningle
Romain Geissler writes:
>
> I have no idea of the LTO format and if indeed it can easily be updated
> in a backward compatible way. But I would say it would be nice if it
> could, and would allow adoption for projects spread on many teams
> depending on each others and unable to re-build everythin
Qing Zhao writes:
> (gdb) where
> #0 0x00ddbcb3 in df_chain_create (src=0x631006480f08,
> dst=0x63100f306288) at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2267
> #1 0x001a in df_chain_create_bb_process_use (
> local_rd=0x7ffc109bfaf0, use=0x63100f306288, top_fla
Marek Polacek writes:
> On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote:
>> On 05/17/2017 04:23 AM, Aldy Hernandez wrote:
>> > Hi folks.
>> >
>> > I've been having troubles comparing the results of different test runs
>> > for quite some time, and have finally decided to whine about it.
Allan Sandfeld Jensen writes:
>
> Yeah. That is just more problematic in practice. Though I do believe we have
> support for it. It is good to know it will automatically upgrade
> optimizations
> like that. I just wish there was a way to distribute pre-generated arch-
> independent training dat
Jürg Billeter writes:
>
> I don't. The idea is to reverse scalar storage order for the whole
> userspace process and then add byte swapping to the Linux kernel when
> accessing userspace memory. This keeps userspace memory consistent
> with regards to endianness, which should lead to high compatib
Martin Jambor writes:
>
> Therefore I would like to ask all seasoned GCC contributors who would
> like to mentor a GSoC student to send a reply to this thread with their
> idea for a project. If you have an idea but you do not want to be a
> mentor then I will consider it only if it is really int
Tom Mason writes:
> Is there any way for me to force the version for these symbols aswell?
It seems pointless because the ABI for these symbols will never change.
-Andi
> If the scope of GCC still intimidates you (but we all struggle with it
> sometimes, trust me), consider reaching out to Andi Kleen and discuss
> his fuzzer project idea with him (he may tell you what to check out and
> experiment with to get the feeling about the task at hand).
On Wed, Mar 07, 2018 at 03:52:15AM +0530, Prathamesh Kulkarni wrote:
> On 3 March 2018 at 16:22, Prateek Kalra wrote:
> > Hello GCC Community,
> > My name is Prateek Kalra.I am pursuing integrated dual
> > degree(B.tech+M.tech) in Computer Science Software Engineering,from Gautam
> > Buddha Univer
> I would suggest that you start with reading through Andi's email to
> another student who expressed interest in that project which you can
> find at: https://gcc.gnu.org/ml/gcc/2018-02/msg00216.html
>
> Andi, do you have any further suggestions what Prateek should check-out,
> perhaps build, exa
On Sun, Jun 10, 2018 at 12:49:44PM +0530, sameeran joshi wrote:
>Hi all,I have been figuring out to work on some project,so while searching
>I found fuzzer implementation project quite interesting,so please can I
>get some information and links about the extension of fuzzer project fo
Witold Baryluk writes:
>
> make BOOT_CFLAGS="$CFLAGS -flto" CFLAGS_FOR_BUILD="$CFLAGS"
> CXXFLAGS_FOR_BUILD="$CXXFLAGS" bootstrap
Easier is to configure with --with-build-config=bootstrap-lto
then you don't need all the magic CFLAGS lines.
> And then waited
>
> I actually waited 5 days... (e
Jed Davis writes:
>
> But is that the right way to do that, do people think? Or should I
> look into making this its own -mcmodel option? (Which would raise the
I would make it a new -mcmodel=... option.
> question of what to call it -- medsmall? smallhigh? altkernel?) Or is
smallhigh sounds
Tobias Burnus writes:
>
> The plan is to translate it as normal loop; however, it would be
> useful if this non-order-dependence could be used by the middle end
> (general optimization or at least for -floop-parallelize-all /
> -ftree-parallelize-loops). Is there a way to tell the middle-end about
Kevin Polulak writes:
>
> I've tried to gain some knowledge by digging through the GCC source
> but haven't come up with much other than the values of the DW_*
> constants which isn't that important. Are there any files in
> particular I should be looking at?
>From the gcc internals manual:
* D
David Brown writes:
>
> Some toolchains are configured to have a series of "init" sections at
> startup (technically, that's a matter of the default linker scripts
> and libraries rather than the compiler). You can get code to run at
> specific times during startup by placing the instructions dir
Artem Shinkarov writes:
>
> 1) Currently in C we cannot provide information that an array is
> aligned to a certain number. The problem is hidden in the fact, that
Have you considered doing it the other way round: when an optimization
needs something to be aligned, make the declaration aligned?
> Or I am missing someting?
I often see the x86 vectorizer with -mtune=generic generate a lot of
complicated code just to adjust for potential misalignment.
My thought was just if the alias oracle knows what the original
declaration is, and it's available for changes (e.g. LTO), it would be
like
"H.J. Lu" writes:
> Hi,
>
> ---plugin option for ar/nm is very long. I am proposing to add
> a --plugin-gcc option. It can be implemented with
>
> 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4.
> 2. Define LTOPLUGINSONAME for ar/nm.
> 3. For --plugin-gcc, ar/nm call popen using environ
Ulrich Drepper writes:
>
> It's not guaranteed to work in general. The problem to solve is that
> I know the function which is called is not clobbering any registers.
> If I leave it with the normal function call gcc has to spill
> registers. If I can hide the function call the generated code ca
> > At least the Linux kernel has a couple such cases ("nasty inline asm to
> > hide register clobbering in calls") and it's always ugly and hard to
> > maintain.
>
> It would simply be an alternate ABI that makes all registers callee-saved?
Yes exactly that.
-Andi
--
a...@linux.intel.com -- Sp
On Thu, Nov 17, 2011 at 03:14:57PM +0100, Torvald Riegel wrote:
> We are aware that the TM language constructs should be documented in
> extend.texi. However, the most recent public version of the C++ TM
> specification document is outdated, and a new version is supposed to be
> released in a few
Sandra Loosemore writes:
>
> I'm still finding my way around LTO; can anyone who's more familiar
> with this help narrow down where to look for the cause of this? I
> don't even know if this is a compiler or ld bug at this point. I'm
I would look into the interaction between the LTO plugin and
> Anyway, the problem here isn't that I particularly care about coming up
> with some workaround to make LTO work, but rather that tests from the
> gcc testsuite are failing on this target because of what looks like
> buggy LTO behavior instead of bugs in the target support, and I wanted
> to b
Richard Guenther writes:
>
> You then can do
>
> gcc $OPTIONS -flto a.c -o a.o
> gcc $OPTIONS -flto b.c -o b.o
> gcc $OPTIONS -ffixed-r9 -ffixed-r10 -flto d.c -o d.o
> gcc $OPTIONS -ffixed-r9 -ffixed-r10 -flto e.c -o e.o
> gcc $OPTIONS -flto a.o b.o -o non-fixed-reg-part.o -r -nostdlib
> gcc
Bradley Lucier writes:
> and RBX is used by XLAT, XLATB.
XLAT* is generally not used anymore, certainly not in gcc generated code.
> Are 12 registers not enough, in principle, to do scheduling before
> register allocation?
You want to limit gcc to only 12 registers?
> I was getting a 15% sp
Richard Guenther writes:
>
> The wish for more granular and thus smaller debug information (things like
> -gfunction-arguments which would properly show parameter values
> for backtraces) was brought up. We agree that this should be addressed at a
> tools level, like in strip, not in the compiler
> To make the above work first the external tools have to add the
> capabilities, just implementing it in GCC doesn't work for us.
Ok, but there's more to building software, than just building rpms.
For example I can definitely see a common use case where a program
is built with line number and
Richard Guenther writes:
>
> It's likely because you have long long vars on the stack which is
> faster when they are aligned.
It's not faster for 32bit.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
Steven Rostedt writes:
>
> And frame pointers do add a little overhead as well. Too bad the mcount
> ABI wasn't something like this:
>
>
> :
> callmcount
> [...]
>
> This way, the function address for mcount would have been (%esp) and the
> parent address woul
John Regehr writes:
> See here:
>
> http://embed.cs.utah.edu/embarrassing/
>
> There is a lot of data there. Please excuse bugs and other
> problems. Feedback would be appreciated.
>
I was a bit surprised by the icc results, because traditionally icc doesn't
have a good reputation for good co
On Mon, Dec 14, 2009 at 09:30:57AM -0700, John Regehr wrote:
> I also noticed these testcases but decided to leave them in for now.
> Obviously the code is useless, but it can still be interpreted according to
> the C standard, and code can be generated. Once you start going down the
> road of
John Regehr writes:
>> I would only be worried for cases where no warning is issued *and*
>> unitialized accesses are eliminated.
>
> Yeah, it would be excellent if GCC maintained the invariant that for
> all uses of uninitialized storage, either the compiler or else
> valgrind will issue a warni
> I am not a valgrind expert so, take the following with a grain of salt
> but I think that the above statement is wrong: valgrind reliably detects
> use of uninitialized variables if you define 'use' as meaning 'affects
> control flow of your program' in valgrind.
It works in some cases for the s
°àâÕÜ ÈØÝÚÐàÞÒ writes:
> Hi,
>
> I have a project in mind which I'm going to propose to the GCC in terms of
> Google Summer of Code. My project is not on the list of project ideas
> (http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very
> interesting
> for me to hear any opinions an
Robert Dewar writes:
>
> Sure you can run some benchmarks and look for missed optimization
> opportunities, that's always worth while, for instance people
> regularly compare gcc and icc to look for cases where the gcc
> optimization can be improved
OT, but there's lots of cool data on all of thi
"Brian O'Mahoney" writes:
>
> Last, a word to the wise, compiler developers, are by nature fairly agressive
> but, unless you want to work on gcc itself, it is wise to stay a bit behind
> the bleeding edge, and, unless your systems are excellently backed up,
> ___DONT_BUILD_THE_KERNEL___ with an
Steve Ellcey writes:
> The first one is: would it be reasonable to compile crt files with
> -mcmodel=large by default on the x86-64 linux platform? Currently the
> crt files are not compiled with this option and that makes it impossible
> to compile a program where the text segment is above 4GB
On Tue, Jan 27, 2009 at 09:33:17AM -0800, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
> > Steve Ellcey writes:
> >
> > > because the crt files can't handle the large code model if they aren't
> > > compiled with this opt
On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>
> > He'll get much better code by putting the program into a -fPIC .so,
> > loading it from a small stub and then unmap the stub.
> > large model generates really very bad code because all jumps
> > will be indirect.
>
> Is it also
On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote:
> Andi Kleen wrote:
> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
> >>> He'll get much better code by putting the program into a -fPIC .so,
> >>> loading it from a small stu
"Joseph S. Myers" writes:
>
> The AMD instruction sets now have public documentation. Other
> manufacturers may well follow suit, especially if enough people caring
> about free software and open documentation choose which GPU to buy on such
> a basis (which is obviously a personal choice for
Ian Lance Taylor writes:
> I've put a project proposal for split stacks on the wiki at
> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
> of a single thread to be split into discontiguous segments, thus
> permitting many more threads to be active at one time without worryi
Steven Bosscher writes:
> case OPT_mfixed_range_:
> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
> if (!strcmp (arg, processor_alias_table[i].name))
> {
> ia64_tune = processor_alias_table[i].processor;
> + if (ia64_tune ==
Robert Dewar writes:
> Sebastian Pop wrote:
>> On Fri, Apr 24, 2009 at 08:12, Robert Dewar wrote:
What would we have to do to make PPL and CLooG required to build GCC?
>>> Why would that be desirable? Seems to me the current situation is
>>> clearly preferable.
>> To enable loop transforms
On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote:
>
> I'm working on a little patch that extends the data produced for the
> little-used (?) -g1 mode. Normally, this produces very little DWARF
> data (basically just function declaration locus, PC range, and basic
> backtrace-enab
> Another possibility, though a much bigger amount of work, would be to
> introduce -g options like -f. The presence of such an option would
> imply -g1 or higher, and then you could add -gparameters,
> -gline-numbers, -gvar-tracking, -gmacros, etc.
I would like to have that.
-Andi
--
a...@linu
On Sat, Apr 25, 2009 at 10:30:51AM -0700, Ian Lance Taylor wrote:
> Andi Kleen writes:
>
> > On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote:
> >>
> >> I'm working on a little patch that extends the data produced for the
> >> little-
Xinliang David Li writes:
>
> If the idea is generally accepted, I will prepare a series of patches
> and submit them to gcc trunk.
I was reading your wiki page. Interesting idea.
One aspect that wasn't clear to me on reading it was how different
compiler arguments for different files are handl
On Tue, May 05, 2009 at 10:25:13AM -0700, Xinliang David Li wrote:
> Andi,
>
> On Tue, May 5, 2009 at 1:49 AM, Andi Kleen wrote:
> > Xinliang David Li writes:
> >>
> >> If the idea is generally accepted, I will prepare a series of patches
> >> and submi
"Joseph S. Myers" writes:
> On Tue, 12 May 2009, Chris Lattner wrote:
>
>> 1. I have a hard time understanding the code size numbers. Does 10% mean
>> that
>> GCC is generating 10% bigger or 10% smaller code than llvm?
>
> I have a different comment on the code size numbers: could we have
> co
> From looking http://vmakarov.fedorapeople.org/spec/I2Size32.png it does
> not look that bad at all. For SpecFP it is different, but code size is
The code size seems to be much worse than LLVM at least, unless
I misread the graphs.
Also my comment was in regard of the suggestion to try -Os --
Mark Mitchell writes:
>
> I think virtual functions are on the edge; quite useful, but do result
> in the compiler adding a pointer to data objects and in uninlinable
> indirect calls at run-time. Therefore, I would avoid them in the
Is that still true given profile feedback and the recent
devir
Hi Honza,
Here's an idea to make it easier to manually annotate
large C code bases for hot/cold functions where
it's too difficult to use profile feedback.
It's fairly common here to call function through
function pointers in manual method tables.
A lot of code is targetted by a few function poi
Richard Guenther writes:
>
> Iff the inheritence is restricted to initializers like in the above example
> it should be straight-forward to implement in the frontends.
Great.
For best results would need some inheritance to callees too, if the
callees are not called by other non annotated code (t
1 - 100 of 221 matches
Mail list logo
