On Sat, Jul 8, 2017 at 1:30 AM, Michael Clark wrote:
> Why does gcc branch on _Bool, but emits a conditional move for an integer?
> can it emit cmovne instead of branching? also curious where one would change
> this to learn about GCC internals.
The RTL generated for the int and _Bool case is di
On Mon, Jul 31, 2017 at 6:49 PM, Joel Sherrill wrote:
>
> Long ago, there was a code size regression tester for at least
> ARM. Is that still around?
There used to be autotesters from CSiBE. Something still appears to
exist (http://www.csibe.org/old/) but the last time I tried to run the
benchmar
On Fri, Apr 29, 2016 at 12:52 PM, Kyrill Tkachov wrote:
> I'm looking at an issue in RTL ifcvt and I'm trying to understand the way
> edges between
> basic blocks are treated and in particular what is the canonical use of
> EDGE_FALLTHRU.
> Is it governed by the conditional jump condition?
>
> In f
On Sat, Jul 4, 2015 at 3:45 PM, Ajit Kumar Agarwal wrote:
> I am not sure why the above optimization is not implemented in GCC.
-fsplit-ivs-in-unroller
Ciao!
Steven
On Mon, May 11, 2015 at 7:37 PM, Georg-Johann Lay wrote:
> BTW, what's the policy about unconditional jumps at that time? There are
> plenty of unconditional jumps around and all are legitimate; just this one
> generated by cse1 is wrong?
If you're in cfglayout mode, then there should be no uncon
On Wed, Apr 22, 2015 at 6:59 PM, Toon Moene wrote:
> Why is loop fusion important, especially in Fortran 90 and later programs ?
>
> Because without it, every array assignment is a single loop nest, isolated
> from related, same-shape assignments.
Why is this a bad thing? When you're talking about
On Wed, Apr 22, 2015 at 1:45 AM, Steve Ellcey wrote:
> I have a question about inserting code into a function being compiled by
> GCC. Basically I want to set a hard register at the beginning of a
> function like is being done below. If I compile the program below on MIPS
> the $16 register gets
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
> I might be wrong but I think you have a bloated code because you use
> scratches. I already told several times that usage of scratch is always a
> bad idea. It was a bad idea for an old RA and is still a bad idea for IRA.
> The usage of
On Mon, Mar 9, 2015 at 7:59 PM, vax mzn wrote:
> w.r.t, https://gcc.gnu.org/wiki/Speedup_areas where we want to improve the
> performance of splay trees.
>
> The function `splay_tree_node splay_tree_lookup (splay_tree, splay_tree_key);'
> updates the nodes every time a lookup is done.
>
> IIUC, Th
On Tue, Feb 17, 2015 at 9:45 AM, Ajit Kumar Agarwal wrote:
> Hello All:
>
> I can see the Loop invariant pass in the GCC on RTL considering the register
> pressure and the cost manipulation
> With respect to SET destination node in RTL.
>
> The Loop invariant takes care of only address arithmetic
On Mon, Sep 29, 2014 at 12:09 AM, FX wrote:
> Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401
>
>
>> This is easy to see with a simple C test case:
>>
>> //__attribute__ ((optimize("strength-reduce")))
>> int foo (float x) { return __builtin_isnan(x); }
>>
>> Compiled with -O3
On Sun, Sep 28, 2014 at 10:28 PM, FX wrote:
>> It looks like parse_optimize_options has nothing c-family specific in
>> it, so it could be moved to attribs.c. Then you'd use
>> build_optimization_node to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION, as
>> done in c-common.c:handle_optimize_attribute.
>
On Sun, Sep 28, 2014 at 5:24 PM, FX wrote:
> I’m trying to get the Fortran front-end to add function-specific optimization
> flags to certain functions (those that request IEEE compliance through use of
> the specific Fortran module). It seems simple enough, adding the attribute to
> the fndecl,
On Wed, Sep 24, 2014 at 11:47 PM, Ian Lance Taylor wrote:
> On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher wrote:
>> Are you using -pipe? AFAIR this still isn't the default, even on
>> GNU/Linux, but it is typically a lot faster than without.
>
> Is that true even wh
On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka wrote:
> Libreoffice shows that GCC needs about twice as much of system time. According
> to profiles, good part is the ugly way we pass stuff down to assembler and
> other part is memory use during the copmilation stage.
Are you using -pipe? AFAIR thi
On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
> Last time I tried, there are several passes after loop_done and before
> auto-inc-dec can't handle auto-increment addressing mode, including
> fweb.
It surprises me that pass_web can't handle AUTOINC. Perhaps I'm off my
rocker, but it's always bee
On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
> 1. It is well known that register renaming is a big help to register
> allocation, but in gcc's backend, the web pass is far before RA, there
> are about 20 passes between them. Does it mean register renaming can
> also heavily benefit other optim
On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders wrote:
>> Of course we should make things more explicit here and move all data
>> structures out of GC that are explicitly freed. Work in that direction is
>> welcome. The CFG is in GC memory because it indirectly refers to trees (the
>> sing
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> So... I've been getting my feet wet with LTO and debugging and I noticed a
> seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
Eh, sorry I can't actually answer your question but, e
On Sat, Jul 26, 2014 at 7:57 PM, Andreas Schwab wrote:
> NightStrike writes:
>
>> On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote:
>>>
>>> pinskia writes:
>>>
>>> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote:
>>> >>
>>> >> Ian Lance Taylor writes:
>>> >>
>>> >>> At the same time, we face th
(NONJUMP_INSN_P (insn)
> && (! reload_completed
> || (GET_CODE (PATTERN (insn)) != USE
> && GET_CODE (PATTERN (insn)) != CLOBBER))));
> }
>
> It is clear that someone [Steven Bosscher] thought it needs fixing but what's
> the prob
On Thu, Jan 23, 2014 at 10:27 PM, Eric S. Raymond wrote:
> I have not run direct checks on the quality of the optimized code, but
> reports from others that it is improved seem plausible in light of
> the fact that GCC's optimization technology is two decades older in
> origin.
Yay, another "fact"
On Thu, Jan 23, 2014 at 6:49 PM, Eric S. Raymond wrote:
> (Redirected to the proper lists, excluding emacs-devel.)
This is not the proper list. "gcc@ is a ... list for general
development discussions about GCC." (xf
http://gcc.gnu.org/lists.html). Most of this pointless discussion has
nothing to d
On Tue, Dec 10, 2013 at 4:17 PM, Claudiu Zissulescu wrote:
> Hi,
>
> Our ARC processor has a multiplication operation that returns a 64 bit result
> into a fixed register pair named like this:
>
> mlo:DI=zero_extend(r159:SI)*sign_extend(r181:SI)
>
> The GCSE rtl pre step has some difficulties to
On Sun, Dec 8, 2013 at 8:28 PM, David Edelsohn wrote:
> On behalf of the entire GCC Steering Committee, it gives me
> great pleasure to welcome Joseph Myers as the newest member of the
> GCC Steering Committee. We hope that everyone will join us to wish him
> all of the support and wisdom f
On Wed, Nov 27, 2013 at 6:47 AM, Jeff Law wrote:
> How about rtl_merge_blocks getting smarter about removing BARRIERS between
> the blocks-to-be-merged?
It'd be breaking away further from the rule that merge_blocks should
only work if can_merge_blocks.
(But that isn't enforced in cfgrtl mode right
On Tue, Nov 26, 2013 at 11:05 PM, Jeff Law wrote:
> On 11/26/13 14:41, Steven Bosscher wrote:
>>
>>
>> I suppose with "cruft" you mean the dead end in the CFG due to
>> builtin_unreachable, correct?
>
> Yes.
>
>
>
> > If so, then I suppose
On Tue, Nov 26, 2013 at 10:03 PM, Jeff Law wrote:
>> I believe the proper fix would be to not recognize this as an
>> if-conversion block candidate in cond_exec_find_if_block.
>
> That's easy enough to do, but leaves a fair amount of useless cruft in the
> IL and ultimately the resulting code. If
On Tue, Nov 26, 2013 at 8:20 PM, Jeff Law wrote:
>
> The jump threading changes have exposed a latent bug on machines with
> conditional execution such as the ARM.
>
> Going into the last conditional execution pass we have:
>
> [ ... ]
> (insn 16 60 17 2 (set (reg:CC 100 cc)
> (compare:CC (
On Fri, Nov 22, 2013 at 6:16 PM, Jeff Law wrote:
>> I am still not convinced jump threading is good for target with predicated
>> execution (assuming no fix for if-conversion). I am doing benchmarking on
>> our target now.
Try disabling only jump threading of back edges, loop latches, and
jump thr
On Tue, Nov 19, 2013 at 4:20 PM, Diego Novillo wrote:
> Currently, many targets are broken because of -Werror. I was thinking
> of fixing them, but unless we keep them clean with a buildbot they
> will regress.
How nobel. But isn't this what we have port maintainers for?
I'd say: Let it be! If a
On Wed, Nov 13, 2013 at 11:15 AM, Richard Biener wrote:
> You know - 'tree's were a design decision (well, just my guess - I wasn't
> around 25 years ago ...). They are a perfect match to represent an AST.
I'd argue against that, but perhaps some other time, in a different thread...
> So I'd sa
On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
> Well, he doesn't even consider that the exact same "tree rant" applies
> to frontend code.
That's not entirely true, either. Most front ends already use their
own IL in the parser (only C++ uses 'tree' for everything).
What worries me most
[Sorry for double post - gmail insists that "GCC" is gcc-patches@, not
gcc@ :-/ ]
Hello,
Here is a non-comprehensive list of macros that are used with a
function passed to the macro's argument, and the macro evaluates that
argument at least twice:
gimple.c: && (CONVERT_EXPR_CODE_P (gim
Hello,
powerpc64-linux bootstrap is broken by the libsanitizer merge:
In file included from
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:21:0:
/usr/include/asm/stat.h:31:2: error: 'ino_t' does not name a type
ino_t st_ino;
^
/usr/include/asm/stat.h:34:2:
On Sun, Aug 11, 2013 at 10:04 PM, Gerald Pfeifer wrote:
> It's my pleasure to announce the appointment of Steven Bosscher
> as RTL optimizers reviewer.
>
> Congratulations and Happy Hacking, Steven!
>
> Gerald
>
> PS: Please update MAINTAINERS accordingly.
Thanks
On Tue, 14 May 2013 10:38:02 -0400, David Taylor wrote:
> There are other reasons besides the DWARF verboseness, but they are
> solvable. The verboseness (over 10x increase in the size of the elf
> file) is a show stopper.
People keep saying that here from time to time. You said it earlier
this y
et but sched-dbr looks through the
call to find the sub.
Ciao!
Steven
/* Perform delay slot filling.
Copyright (C) 2013 Free Software Foundation, Inc.
Contributed by Steven Bosscher.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under
the terms of th
On Thu, Apr 18, 2013 at 12:58 PM, Bernd Schmidt wrote:
> In general I think if a new target wants more than one delay slot, it
> should try to use the C6X method instead of reorg.c. It would be nice
> for someone to try it on a target like mips or PA as well;
Agreed on both points. I actually cons
On Thu, Apr 18, 2013 at 6:22 AM, Jeff Law wrote:
> On 04/17/2013 03:52 PM, Steven Bosscher wrote:
>>
>> First of all: What is still important to handle?
>>
>> It's clear that the expectations in reorg.c are "anything goes" but
>> modern RISCs (every
Hello delay-slot target maintainers :-)
As you know, I'm playing with a new for-now-toy delay slot filling
pass that preserves the CFG, and uses DF and sched-deps instead of
resource.c. It's now beginning to take form enough that I run into the
to-be-expected unexpected problems and questions. The
Hello,
What is the correct way to see if a register is used by a call and not
used to e.g. hold the address of the callee? For example,
20: %g1:DI=high(`baz')
22: %g1:DI=[%g1:DI+low(`baz')]
23: %o0:DI=0x4
24: %o0:DI=call [%g1:DI] argc:0
In the above code (from the .210.postreload dum
On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote:
> On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote:
>
>> Are there any reasons against removing !TARGET_BIG_SWITCH support? It
>> would really help if this code can go away...
>
>
> Yes, branch distances are limite
Hello,
I'm trying to get to a point where the CFG is useable even in the
delay-slot filling pass (dbr_schedule) and I'm currently stuck on a
transformation that the PA port does if -mno-big-switch is in effect.
With !TARGET_BIG_SWITCH, the PA port "explodes" a JUMP_TABLE_DATA to
real code, i.e. a
On Tue, Mar 26, 2013 at 10:31 AM, Richard Biener wrote:
> On Mon, Mar 25, 2013 at 10:23 PM, Dinar Temirbulatov wrote:
>> The error in 252.eon was due to incorrect setup. Also "if (count >
>> 3*PARAM_VALUE (PARAM_SWITCH_JUMP_TABLES_BB_OPS_LIMIT))" does not look
>> correct, and probably it is better
Hello,
Below are some compile times and sizes I measured for a bunch of GCC releases.
The test compilers are listed in the tables. All of them were compiled
with gcc 4.7.2 (i.e. not bootstrapped). Test machine is gcc110
(powerpc64) which was otherwise idle. Times are "user" times in
seconds, from
On Sat, Mar 16, 2013 at 3:04 PM, Jakub Jelinek wrote:
> On Sat, Mar 16, 2013 at 02:51:03PM +0100, Steven Bosscher wrote:
>> On Sat, Mar 16, 2013 at 9:55 AM, Jakub Jelinek wrote:
>> > Quality Data
>> >
>> >
>> >
On Sat, Mar 16, 2013 at 9:55 AM, Jakub Jelinek wrote:
> Quality Data
>
>
> Priority # Change from Last Report
> --- ---
> P11 + 1
> P2 68 + 3
> P3 11 - 7
> --- --
On Sun, Mar 10, 2013 at 22:54, Matt Davis wrote:
> I have a particular instance of a
> function call within a function that I am analyzing (and
> transforming). I want the address of that function call, for which I
> do have a gimple_call instance of. I want to somehow create a symbol
> identifyi
On Sun, 10 Mar 2013 at 13:51, Matt Davis wrote:
> I have a GIMPLE_CALL gimple object. I want to get the tree node
> representing the callsite for this particular instance of a call, how
> can I get this information?
The GIMPLE_CALL gimple object *is* the call site.
Ciao!
Steven
On Mon, Feb 25, 2013 at 10:51 PM, Eric Botcazou wrote:
>> That's what I believe, too. Still, combine appears to add REG_UNUSED
>> notes for clobbers intentionally. Do you know why it does that?
>
> Hmm, right, it apparently clearly wants to immediately close the "live" ranges
> it creates by addin
On Mon, Feb 25, 2013 at 10:48 AM, Eric Botcazou wrote:
>> It seems to me that a REG_UNUSED note on a CLOBBER is unnecessary, and
>> it also goes against the documented purpose of a REG_UNUSED note in
>> reg-notes.def:
>>
>> /* Identifies a register set in this insn and never used. */
>> REG_NOTE (
Hello,
Is it necessary for an insn to have REG_UNUSED notes for a CLOBBER?
There are lots such notes on x86 for the flags register:
11: {r68:DI=r61:DI<<0x8;clobber flags:CC;}
REG_DEAD r61:DI
REG_UNUSED flags:CC
In most places where the compiler looks at REG_UNUSED notes, it is for
Hello Vlad,
Back in October, you added a patch to remove extra clobbers introduced by LRA:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02531.html
This also disables some -frename-registers opportunities (a few 100 on
x86-64 for my collection of cc1-i files).
Do you think it's be possible (and w
On Mon, Jan 28, 2013 at 4:47 PM, Diego Novillo wrote:
> On Sun, Jan 27, 2013 at 7:09 AM, Steven Bosscher wrote:
>
>> Is this a known issue?
>
> No, thanks for the report. I'll try to see what's going on (though
> you may need to ping me in a few days).
http://www.
Hello Diego,
There still appears to be an issue with the vec.h changes, the
detailed memory stats are not very informative. The allocation lines
are shown in vec.h without further details:
t8000.log:vec.h:1268 ((null)) 0:
0.0% 40 4: 0.0
On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it
Hello,
In this stabs vs. dwarf discussion, so far it's more been about
assumptions than numbers. So let's throw in some numbers!
The following debug sizes are for CSiBE-v2.1.1 on mipsisa64-elf, with
the LRA branch at r195108. All CSiBE test cases are packages written
in C.
Debug size is computed
Hello,
Consider this test case:
-- 8<
int a;
__attribute__((__noinline__,__noclone__,__pure__))
int use (int b)
{
return b * 2 + 4 + a;
}
int foo (int b, int c, int d)
{
int res, r = 0;
res = use (b);
if (c)
r = res;
return r;
}
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
res = b * 2 + 4;
if (c)
{
if (d)
r = res;
else
__builtin_unreachable ();
}
return r;
}
This is typical for code in GCC itself in places wher
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the
On Sat, Dec 22, 2012 at 5:15 PM, Steven Bosscher wrote:
> Vlad, I've set up auto-testers for the lra-branch on gcc110
> (powerpc64) and gcc66 (ia64). They run within 24 hours after something
> changes on the lra-branch, and post test results to gcc-testresults if
> build+test was
On Fri, Dec 21, 2012 at 1:09 AM, David Daney wrote:
> The last time I checked, gcc/REVISION is only set to the proper value by
> running contrib/gcc_update.
Right. Well, that makes things easy :-)
Vlad, I've set up auto-testers for the lra-branch on gcc110
(powerpc64) and gcc66 (ia64). They run w
Hello,
I've bootstrapped&tested the LRA branch on ia64 and posted the results
to gcc-testresults
(http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01782.html).
Unfortunately there's nothing in the message that shows that this
wasn't a trunk checkout but the LRA branch.
Is it possible to identify
On Thu, Dec 13, 2012 at 2:40 PM, John Marino wrote:
> Everything I have said is a fact, please illustrate which statement I made
> seems emotional.
Joining in this discussion at all? I wish *bsd people were just as
responsive to bug reports...
Ciao!
Steven
On Thu, Dec 13, 2012 at 2:19 PM, Richard Biener wrote:
> Gerald runs regression tests on both i386 and x86_64 freebsd (though some old
> versions of it). We do have a listed maintainer for freebsd. Apart from
> build
> issues I am not aware of frequent freebsd specific bugs.
Gerald's test for i
On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote:
> Which clause are you invoking to remove it from the primary tier list?
> Richard claimed "they are not at all happy with GPLv3". That's not a reason
> listed on your reference. He also claimed they "not using still maintained
> compilers" whic
On Thu, Dec 13, 2012 at 12:59 PM, Robert Dewar wrote:
>
>> Intel stopped producing embedded 386 chips in 2007.
>
>
> Right, but this architecture is not protected, so the
> question is whether there are other vendors producing
> compatible chips. I don't know the answer.
Ralf has found one such a
On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote:
> Dropping bsd as a target architecture just because the BSD distributions
> don't use it is a bit like dropping support for targeting windows just
> because Microsoft didn't use gcc to compile Windows 8.
You're confused. Dropping something as a
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
> I don't speak for FreeBSD, but dropping them from Tier 1 support because
> they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD has dropped GCC for future releases so there's no reason for
it to be a primary platform.
Ciao!
Ste
On Wed, Dec 12, 2012 at 8:39 PM, Robert Dewar wrote:
> On 12/12/2012 1:01 PM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> Linux support for i386 has been removed. Should we do the same for GCC?
>> The "oldest" ix86 variant that'd be supported would
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The "oldest" ix86 variant that'd be supported would be i486.
The benefit would be a few good cleanups:
* PROCESSOR_I386 / TARGET_386 can be removed
* X86_TUNE_DOUBLE_WITH_ADD can be removed (always true)
* X86_ARCH_C
On Tue, Dec 11, 2012 at 6:55 PM, Martin Jambor wrote:
> some IPA passes do have on-the side vectors with their information
> about each cgraph node or edge and those are independent GC roots.
> Not all, but many (e.g. inline_summary_vec or ipa_edge_args_vector) do
> have pointers to other GC data,
On Tue, Dec 11, 2012 at 5:11 PM, Diego Novillo wrote:
> On Mon, Dec 10, 2012 at 1:25 PM, Steven Bosscher wrote:
>> This all made me wonder why we can't use the known hierarchy of the
>> intermediate representations. Ideally, there should be only two
>> classes of objec
Hello,
While trying to bootstrap with GCAC checking enabled and some
instrumentation to measure how often objects are being marked, I
noticed that a lot of cache misses happen because already-marked
objects are being tested again (e.g. via ggc_marked_p). This struck me
as rather odd, until I looke
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
>
> I think if you had changed to it would have a
> better chance to survive broken editors.
I only put back wha
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote:
> On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
>> Hello,
>>
>> Someone broke bootstrap on powerpc64-linux between r194084 and
>> r194141. Anyone else seeing this?
>>
>> Ciao!
>> Steve
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-1
Hello,
Someone broke bootstrap on powerpc64-linux between r194084 and
r194141. Anyone else seeing this?
Ciao!
Steven
../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:338:8:
error: 'void
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES3_S3_S3_RSt8ios
On Sun, Dec 2, 2012 at 12:59 AM, John David Anglin wrote:
> On 1-Dec-12, at 6:45 PM, Steven Bosscher wrote:
>
>>
>> How about this?
>
>
> PA part looks good. Thanks.
Great, thanks! I've committed the PA part with a few typo fixes, and
the reorg.c part as obviou
On Sun, Nov 25, 2012 at 4:44 PM, John David Anglin wrote:
> On 24-Nov-12, at 9:19 PM, Steven Bosscher wrote:
>
>> +;; This machine description is inspired by sparc.md and (to a lesser
>> +;; extend) mips.md.
>
>
> Change "extend" to "extent". D
Hello,
A "Not yet implemented" comment in reorg.c discusses conditional
execution. The comment already existed in the earliest revision in the
repository (r99) so it pre-dates the conditional execution framework
now used by the "Acorn RISC Machine" (better known as ARM nowadays :-)
and how HP-PA c
On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote:
> Richi, ping?
Just guessing... isn't he simply out on Honeymoon?
Those functions were introduced to handle alias sets for spill slots
better, but IIRC this never worked properly. The whole path through
dse_step2_spill is dead.
The code
(sorry for breaking threads... re.
http://gcc.gnu.org/ml/gcc/2012-11/msg00304.html)
On Tue, 20 Nov 2012 09:57:35 +0100, Eric Botcazou wrote:
> > I wouldn't jump to that conclusion too quickly.I think we should be
> > GC free as well, and I doubt I am the only other one.
>
> Dropping the GC mea
On Tue, Nov 6, 2012 at 1:17 AM, Ian Lance Taylor wrote:
> On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote:
>> On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote:
>>>
>>> Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>>&
On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote:
>
> Say, why don't we reserve GCC 5.0 for the first version that gets rid of
> reload? Then let's see if we can get there while the X in 4.X is still in
> single digits!
(see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)
I suppose
On Fri, Nov 2, 2012 at 11:01 AM, Bin.Cheng wrote:
> Hi Steven,
> You mentioned the flag_gcse_las may be very useful for RISC machines in
> thread : http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00031.html
>
> I took some time to understand the code and think it should be workable with
> hoist. Howev
On Fri, Oct 26, 2012 at 2:16 PM, Christophe Lyon wrote:
> I also use some patches posted by Matthew Gretton-Dann, which are
> still under discussion: I will open a PR, and attach these patches
> too. Is it OK?
Yes, that'd be all that's needed to reproduce the bug.
Ciao!
Steven
On Fri, Oct 26, 2012 at 12:26 AM, Andrew Pinski wrote:
> The official wording from SPEC is that the sources are under the same
> license as they are provided to them. It is the data files which are
> under the SPEC license.
Good. So the only things needed to reproduce the problem can be
shared: t
On Fri, Oct 26, 2012 at 12:14 AM, Steven Bosscher wrote:
> On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
>> It looks like something is wrong with the CFG:
>>
>>|
>>19 (COLD)
>> / \
>>/ \
>> 20 (COLD) 21 (COLD)
&
On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
> It looks like something is wrong with the CFG:
>
>|
>19 (COLD)
> / \
>/ \
> 20 (COLD) 21 (COLD)
>\ /
> \ /
> 22 (HOT)
So the partitioning is messed up, the above makes no sense. Where do
Hello,
../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
rs6000_density_test(rs6000_cost_data*)':
../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
was not declared in this scope
This is due to:
2012-10-24 Sharad Singhai
* dumpfile.c (dump_enabled_p): Make
On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote:
> On 24 October 2012 00:42, Steven Bosscher wrote:
>> On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon wrote:
>>> Well, both of these functions appear to check that the 2 blocks to
>>> merge belong to the same pa
On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon
wrote:
> Well, both of these functions appear to check that the 2 blocks to
> merge belong to the same partition, so it should be OK.
In your first email, you said if-convert was merging two blocks from
different partitions. can_merge_block_p() wo
On Tue, Oct 23, 2012 at 5:17 AM, Bin.Cheng wrote:
> Thanks for your explanation.
> Now I understand how df_insn_info is updated when
> deleting/modifying/creating insn. One more question is when and how
> IN/OUT information is updated. GCC calls df_set_bb_dirty when handling
> insns, but I did not
Bin.Cheng wrote:
> It is possible to have register pressure decreased when hoisting an
> expression up in flow graph because of shrunk live range of input
> register operands.
> To accurately simulating the change of register pressure, I have to
> check the change of live range of input operands du
Bin. Cheng wrote:
> Quoting from GCCINT, section "9.5 RTL passes":
> "When optimizing for size, GCSE is done using Morel-Renvoise Partial
> Redundancy Elimination, with the exception that it does not try to
> move invariants out of loops—that is left to the loop optimization
> pass. If MR PRE GCSE
On Tue, Oct 16, 2012 at 7:20 PM, Andi Kleen wrote:
> Vladimir Makarov writes:
>>>
>> As I remember, the performance improvement from this optimization was
>> very small. There were problems in reviewing IRA and I decided to
>> simplify this task.
>>
>> May be it is worth to return to this work.
>
Andrew Pinski Wrote:
>> I figured out that ifcvt.c uses alloca to reserve mem on the stack. this is
>> the point where the segmentation fault occurs.
>
> It is also a regression from what I can tell too from 4.1.x.
And one that's fixed for GCC 4.8.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg
Hello Vlad,
Is it intentional that DF_LR_IN and DF_LR_OUT are not updated after
"Updating elimination of equiv for reg..."? I have some checking in
place in process_bb_lives at the end of the function, and it triggers
on the test case. (Checking code and test case is at the end of this
e-mail.) It
1 - 100 of 961 matches
Mail list logo
