VN between now and 15 minutes ago should probably update again to
pull in the fixes.
Sorry for the inconvenience.
Gr.
Steven
On 3/15/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> The testcase is:
>
> double x;
> q()
> {
> x=x<5?5:x;
> }
>
> compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
> compile t
n SSA form, it's only in GIMPLE form. How can I obtain the
SSA form to apply my code? Is there an option from command line, or
any flag to be setted?
See passes.c, look for "into" and "ssa".
Gr.
Steven
more ports is a goal for GCC, but I
wonder if this set of changes is worth the maintenance burden...
Gr.
Steven
On 3/28/07, Julian Brown <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> All of this feels (to me anyway) like adding a lot of code to the
> middle end to support MEP specific arch features. I understand it is
> in the mission statement that more ports is a goal for GCC, bu
There, we keep the
file/line info on the side, which seems to work rather well.
Gr.
Steven
indows is not a Windows
compiler and should not act like one. If people want to port their
code, they should write their code to be portable way instead of
depending on Windows or GCC stuff.
And what if whatever declspec is (I don't know) actually makes sense?
"Don't be Windows" is not 42.
Gr.
Steven
start the clock? ;)
Gr.
Steven
us if there's a
finished or unfinished patch that I could look at ;-)
Thanks,
Gr.
Steven
fit of this?
Looks like a nice document overall. I hope we can keep it up to date,
it's a good start for new-GIMPLE documentation ;-)
Gr.
Steven
esting this. Do you also have per benchmark compilation
times, perhaps?
Gr.
Steven
be fixed in
the FSF version of GCC 3.4. You can perhaps hire a third party to help
you, or you can upgrade to a more recent version of GCC.
Gr.
Steven
re the code size increase happens because
crossjumping does not happen as often on the dataflow branch as it
does on the trunk.)
Gr.
Steven
irst thing I was planning to look into, in fact.
Gr.
Steven
ot use structure
of bitfields instead of int for target_flags?
Maybe drop support for everything older than i686? ;-)
Gr.
Steven
On 4/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> An interesting observation is that the more hard registers the processor
> has, the bigger slowdown is. Although it might be a coincidence.
Yes, I noticed this too
all, but it is marked as a P2
"regression" anyway)
In summary, I just strongly encourage a more active release manager...
As of course you understand, this is intended as constructive criticism.
Gr.
Steven
I guess I'm on the hook ;-)
Gr.
Steven
y cfglayout changes).
BARRIERs are never inside a basic block, so the patch looks obviously
correct to me. I think you should commit it as such if it passes
bootstrap/testing (preferably on two or three targets, and with
checking enabled of course).
Gr.
Steven
On 4/17/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Indeed. The patch is ok after a re-bootstrap and re-test.
Actually, please don't commit that patch.
Eric Botcazou has already proposed a fix that looks better:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01065.html
Gr.
Steven
er register allocation. Register
pressure is not a problem after register allocation ;-) You just have
more constraints in your scheduling dependency graph.
Gr.
Steven
me along and report silly bugs like this, when perhaps they should
also notice that the efficiency of GCC for -Os has increased
tremendeously in the past few years...
Just my US$0.02 about this particular bug.
Gr.
Steven
-linux 342 337 -1.5%
2004-12-05 2006-06-17 diff
bfin-elf314 312 -1%
Maybe you can look at the development of code size of AVR over time,
and show a different trend, but I'd be surprised.
Gr.
Steven
ve shown that for this test case GCC actually may
have regressed on every target, you've shown that perhaps the global
inlining heuristics should be changed. May well be, for all I know.
Tuning heuristics is always hard and never provably optimal.
Gr.
Steven
On 4/18/07, Joe Buck <[EMAIL PROTECTED]> wrote:
Perhaps the number of arguments should be taken into account as well.
We've been doing that for years.
Gr.
Steven
speculation. Why do you think this? Have you even looked at what
is _really_ going on? Like, some optimizations computing things they
already have available if they'd use the df infrastructure? Maybe you
can be more specific about your concerns, instead of spreading FUD.
Gr.
Steven
e changed registers for CPROP, which runs three times(!). It is
easy to really speed this pass up by using the df framework to e.g.
replace things like oprs_unchanged_p and the whole reg_avail_mess.
Gr.
Steven
.
Changing the dataflow solvers is one thing. Changing a fundamental
assumption in the compiler, namely that pseudoregs are shared, is
another. We rely on that property in so many places. It would not
require rewriting parts of the compiler, but rewriting the entire
backend.
Gr.
Steven
down where the difference comes from,
as most of the differences seemed unimportant.
The crossjumping issue is already filed: http://gcc.gnu.org/PR30905
The perlbmk benchmark always seems to jump up and down for no obvious
reason. This one will be tough to analyze, I think.
Gr.
Steven
an writes out.
Gfortran writes out the line in the source file that has the issue,
and uses carrets to pin-point the location of the issue. The language
independent infrastructure unfortunately still cannot do this.
Gr.
Steven
ng it to run on my FreeBSD host, and
obviously, it stands no chance to be run against an AVR target system
anyway.
The idea behind that tool is great, I only wish the authors had taken
a class in portable shell scripting before. It's not that all the
world's a Vax these days...
Patches welcome, I guess.
Gr.
Steven
On 5/1/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
Can someone give similar information about LTO? How many people
(full/part time) and how long time it will take? How much work is LTO
compared to the tuple representation?
A vast amount more if we're going to work on LTO with the current
GIMPLE
would have seen a bunch of
suggestions for how you can help with LTO prerequisites that do not
depend on tuples at all. You should look at the bigger picture.
Gr.
Steven
ting. You of course know Gaby is always claiming the exact
opposite: That the compiler must *honor* the inline keyword (explicit
or "implicit", ie. inline in class definitions), that inline is not
a hint but an order that the compiler must follow.
And much to my own surprise, I'm actually beginning to agree with him.
Gr.
Steven
y some of the new ones) for the compile time regression.
...it is unlikely that putting the blame somewhere will magically make
those perceived problems go away.
I can only wonder why we are having this discussion just after GCC 4.0
was branched, while it was obvious already two years ago that inlining
heuristics were going to be a difficult item with tree-ssa.
Gr.
Steven
cific so we can have a clue what you are
talking about? Filing bugs in bugzilla showing the problem
would help.
Gr.
Steven
0.0748 cc1plus
gt_ggc_mx_lang_tree_node
Honza, it seems the cgraph code needs whipping here.
Gr.
Steven
evelopment cycle with branches only merged
in stage 1. In the plan, if you miss stage1, you in theory only
have to maintain the branch through stage2 and stage 3, which is
indeed four months.
Gr.
Steven
the mailing list or with the people who proposed a project,
instead of planning on your own, declaring stage 1, and acting surprised
if your schedule turns out to be inconvenient for some people.
Gr.
Steven
xpect this
> time to be dominated by later inlining/compation explossion so I would
> not take that too seriously (unless proved otherwise by
> cgraph_remove_edge being top on overall profile ;)
After half an hour, I had this:
35490975 82.9876 779873 85.0702 cc1pluscgraph_remove_edge
6706686 15.6821 123588 13.4812 cc1pluscgraph_remove_node
and cc1plus was still not into even the tree optimizers by then.
So I think we can safely say this is a serious bottleneck.
Note that I've seen these cgraph functions show up in less unrealistic
test runs also.
Gr.
Steven
On Tuesday 01 March 2005 02:03, Jan Hubicka wrote:
> You still didn't get into the fun part of actually inlining all the
> inlines in in Gerald's testcase ;)
I'll let it run to the end tomorrow, for at most one full day ;-)
Gr.
Steven
our patch works, I'll try it for 8361 with -fobey-inline too ;-)
Gr.
Steven
tainers have publicly stated they do not
want to be integrated, I suppose you are doing this without their
support?
Gr.
Steven
Oh, and please do not include [EMAIL PROTECTED] in the CC, because that
is not a public list so reply-to-all messages bounce.
Gr.
Steven
On Mar 01, 2005 02:28 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Is it possible and beneficial to have both next pointers
> annotated with chain_next?
Unfortunately it is not. There are other places where this would
be useful, but gengtype does not support this at the moment.
Gr.
Steven
On Tuesday 01 March 2005 02:30, Steven Bosscher wrote:
> On Tuesday 01 March 2005 02:03, Jan Hubicka wrote:
> > You still didn't get into the fun part of actually inlining all the
> > inlines in in Gerald's testcase ;)
>
> I'll let it run to the end tomorrow,
single application anyone cares
of that you need GPC for is also a valid reason, btw.
Gr.
Steven
e optimizers produces a few (and hopefully it
will produce more of them soon), but the bug in the expanders had been
there since the dawn of time. And nobody noticed it before.
So, maybe the extension is not used very much. Perhaps it should be
removed?
Gr.
Steven
sg00681.html
> * Structure Aliasing Part I
Submitted just today:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00896.html
Gr.
Steven
.1476 = -1
(insn 21 19 22 (set (reg:SI 64)
(const_int -1 [0x])) -1 (nil)
(nil))
(insn 22 21 0 (set (reg:SI 62 [ D.1476 ])
(reg:SI 64)) -1 (nil)
(nil))
Strange... Does anyone know a reason for why this happens?
Gr.
Steven
(). Crippling optimizers around
abort is just silly. It's attacking a real problem from the wrong
end. The real problem is that abort() is just not detailed enough.
Gr.
Steven
versioning, you can't use the linkonce idea.
Fun, versioning ;-)
Gr.
Steven
; properly when put in a linkonce section.
That requires an ABI extension, hence ABI support ;-) I had of
course considered this, but we'd some help little help from Mark,
so let's wait and see what he has to say about this.
Gr.
Steven
On Monday 14 March 2005 04:00, Richard Stallman wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information
of the loop ? or the use of the CC ?
> but usually this is couldn't happen in a simple loop, right? the use of CC
> is
> eventually used in a branch, or there is something that I am missing ?
IIRC these notes are for CCO, and you have to move the CC setter
and user together.
Actually I think SMS for CC0 targets is Just Silly to do at all ;-)
Gr.
Steven
the CC setter is always th
very much *not* GIMPLE. So if you enable the lang hook, you
are either going to need a GIMPLE extension (bad), or figure out some
different way to represent this kind of call such that the CALL_EXPR
is proper GIMPLE.
IMHO it is Bad Taste(tm) anyway if get_callee_fndecl must look in
language specific data structures even when it is call from language
independent parts of the compiler, like the tree optimizers.
Gr.
Steven
, but if
it can't be reproduced on a cross, I can ask Andreas Schwab to look
at it a bit more...
Gr.
Steven
typedef enum
{
_URC_NO_REASON = 0,
_URC_FOREIGN_EXCEPTION_CAUGHT = 1,
_URC_FATAL_PHASE2_ERROR = 2,
_URC_FATAL_PHASE1_ERROR = 3,
_URC_NORMAL_STOP = 4,
_URC_END_OF_STACK =
away from loop.c anyway.
Gr.
Steven
On Friday 25 March 2005 01:31, James E Wilson wrote:
> On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
> > I'd suggest trying -fmove-loop-invariants, and report a bug about
> > that instead if it does not move those loop invariants. We really
> > should move away
n why a great
many functions in for example jump.c and the various cfg*.c files can
still not be removed.
Gr.
Steven
form that GCC can produce. All cmp4 patterns in ia64.md
have a single set to p1, and an assembler output template of the form
"cmp4.* %0, %I0 = %3, %2" where the I means "Invert a predicate register
by adding 1".
Perhaps this was done this way to avoid insn patterns with two sets?
Gr.
Steven
to the same speed as
the GCC4 one (runtime of 16.4s with GCC3 vs. 16.7 for GCC4). Usually,
this means IVopts did something that confuses the RTL alias analysis,
which is already just poor for ia64 anyway.
Gr.
Steven
the few things that was not, probably Zdenek knows why.
Gr.
Steven
u have neither tried to implement it yourself, nor provided
a test case to PR20376.
FWIW you could try -fweb and see if it does what you want. And if it
does, you could write a limited webizer patch that works on just loop
bodies after unrolling.
Gr.
Steven
the worklist got more expensive, so there was no overall
win. You need a smart data structure to allow quick inserts and
quick traverses. My implementation wasn't very smart, I mostly did
it to see if it would cause things to fall through the lattice more
quickly (and it did).
Gr.
Steven
e when
> compiled with "-fmodulo-shced -O3" turned on, while
> 5.454 seconds whithout "-fmodulo-sched".
Nice! But makes me wonder... Mustafa, why can doloop_register_get
not just accept the same doloop patterns as the one accepted in
doloop_condition_get?
Gr.
Steven
e when
> compiled with "-fmodulo-shced -O3" turned on, while
> 5.454 seconds whithout "-fmodulo-sched".
Nice! But makes me wonder... Mustafa, why can doloop_register_get
not just accept the same doloop patterns as the one accepted in
doloop_condition_get?
Gr.
Steven
h preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make: *** [build_pyr.o] Error 1
So, See http://gcc.gnu.org/bugs.html for instructions about how to
report this bug.
Gr.
Steven
summit/2003/Alias analysis for intermediate code.pdf"
That code was never included because this analysis is *very* expensive,
and it should be possible to propagate even better alias analysis info
down from the tree optimizers to RTL.
Gr.
Steven'
meone (hi, Diego!) review Dan's patch? And if that patch
does not fix this, we'll have to look for someone else to blame ;-)
Gr.
Steven
On Tuesday 05 April 2005 09:24, Canqun Yang wrote:
> >On Mon, 28 Mar 2005, James E Wilson wrote:
> >> Steven Bosscher wrote:
> >>> OK, so I know this is not a popular subject, but
>
> can we *please* stop
>
> >>> working on loop.c and focus on gett
On Apr 05, 2005 11:47 AM, Canqun Yang <[EMAIL PROTECTED]> wrote:
> Steven Bosscher <[EMAIL PROTECTED]>:
>
> >
> > What happens if you use the memory address unrolling
> patch, turn on
> > -fweb, and set the unrolling parameters properly?
> >
>
&g
mean unrolling the loops without any other
> reason other than just getting them unrolled).
Right, that is what I was thinking too. So that means we have to
improve the new unroller to get it to do what Canqun needs...
Gr.
Steven
this patch, I can bootstrap the reload-branch (c,objc,c++,f95).
Testing is still in progress...
Thanks,
Gr.
Steven
FC3.
>
> Well, it seem that the kernel had nothing to do with the problem.
> Today's bootstrap time was 7,960 seconds.
My suspect is still the ::bind patch. Unfortunately you don't
keep times of libstdc++v3 build times. Not sure how to check
this, except maybe rolling back libstdc++ to March 30...
Gr.
Steven
ve to look at the condition to know?
Who knows an answer? :-)
Gr.
Steven
lution is of course to have an IR that we can
stream to disk, *sigh* ;-)
Gr.
Steven
onsidering it. I'll let you know if I've firmly decided that
> your patch will not be in RC2.
Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html
to your list? If the patch is OKed by rth (ping! :-), it would fix a
-fPIC ICE regression on IA32 and AMD64.
Gr.
Steven
schedule groups.
* sched-ebb.c (init_ready_list): Ditto.
* (move_insn, set_priorities): Ditto.
Vlad, can you explain this change? Can I safely clean up this function,
or should we still avoid calling reemit_notes more than once for each
insn???
Gr.
Steven
n, rtx last)
{
reorder_insns (insn, insn, last);
SCHED_GROUP_P (insn) = 0;
return reemit_notes (insn, insn);
}
I'll give it a look.
Gr.
Steven
y, and hence the loop gets moved out of line.
Have you tried with the patch to re-enable the loop header copying
predictor: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02577.html?
It sounds like you might want to try that first...
Gr.
Steven
On Wednesday 13 April 2005 20:46, Pat Haugen wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 09:39:55 AM:
> > On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> > > When we have a test block gating whether a loop should be
> > > entered, the new
icies can clearly
> be dangerous (if none of these cc1 files contains K&R prototypes,
> perhaps we could drop parser support for pre-ANSI C, etc...).
That is something completely different. It is not even in the same
category, you're comparing breaking standard conformance with removing
dead code.
Gr.
Steven
sion to make, though ;-)
Gr.
Steven
P.S. I wonder why the code for the best edge in tracer.c:better_p is
not the same as the code in bb-reorder -- or why we have two trace
finding algorithms in one compiler... Honza??
lease let me know if the patch is approved for
> mainline?
It was already rejected by rth.
Gr.
Steven
rlier explanations about that,
as well as the proof of that, such as a number of fold patches, including a
patch by you to fix expand_mult for negative constants. These patches all
fixed missed optimizations I identified by looking at what CSE was still
catching. There was a lot more to that than pushing patches on test boxes.
> I may decide the patch is perfect as written.
I don't see how you can with such an ill-informed view of the RTL optimizers.
It's a rather arrogant thing to say anyway. Apparently you think that only
you are diligent enough to decide what parts of the RTL optimizations must
stay, and what parts can go away. That surprises me, given the completely
false statements you make about the RTL optimizers.
But anyway, since you are the Superior Being with approval rights here and I
don't want to be in this kind of discussion all the time, I am just not going
to work on simplifying CSE anymore.
Gr.
Steven
will ever go away. And the RTL passes corresponding to
> > > instruction selection (combine), register allocation (reload) and
> > > scheduling will almost certainly be RTL-level tasks/passes.
> Surely you
> aren't suggesting doing register allocation at the tree level?
Oh, definitely not, no. Heh. Now _that_ would be really ugly, if
it is possible at all. Linus suggested once in this list that GCC
should do that... ;-)
Gr.
Steven
nsformation CSE makes is profitable.
Well, obviously we are having this discussion because a patch got
blocked on this very assumption.
Gr.
Steven
cribed on one of the Wiki pages,
"http://gcc.gnu.org/wiki/Exploiting Dual Mode Operation"?
Gr.
Steven
; straight to the trash can. You mail is
obviously not spam, but somehow you've ended up on the blacklist
here :-/
Dunno what to do about that...
Gr.
Steven
.L2
popl%ebp
ret
.size g, .-g
.ident "GCC: (GNU) 4.1.0 20050412 (experimental)"
.section.note.GNU-stack,"",@progbits
Looks a bit more like your optimal code ;-)
Gr.
Steven
On Friday 22 April 2005 04:43, Canqun Yang wrote:
> Steven Bosscher <[EMAIL PROTECTED]>:
> > On Thursday 21 April 2005 17:37, Mostafa Hagog wrote:
> > > The other thing is to analyze this problem more
>
> deeply but I don't have
>
> > > IA64.
>
ter register allocation some insns
do not have all their operand constraints satisfied, so reload needs
to fix up something, but it cannot use the registers it needs.
But since you're not showing what you've added, it's hard to tell what
the real problem is.
Gr.
Steven
On Monday 25 April 2005 10:48, Zdenek Dvorak wrote:
> > the CFG inliner will hit bsi_for_stmt hard.
>
> This is just because CFG inliner is badly written; Honza has already
> fixed that in his private tree.
The CFG inliner is badly written, sure, but the problem is before
that. It's finding the
blem
> for older platforms will never be made.
Maybe the older platform should stick to the older compiler then,
if it is too slow to support the kind of compiler that modern
systems need.
Gr.
Steven
On Wednesday 27 April 2005 22:06, Paul Koning wrote:
> >>>>> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
>
> Steven> On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
> >> If no one builds natively on older platforms, the recogni
tions that tree expansion now does,
that should be moved to the tree optimizers. See e.g. PR14841.
I don't know if we have PRs for other optimizations expr.c&friends
do.
Gr.
Steven
mainline and on the GCC 4.0 branch.
Should we release a new GCC 4.0 RSN and recommend that people do not
use GCC 4.0.0? Or should we maybe add a notice somewhere about this
bug?
Thoughts?
Gr.
Steven
On Apr 28, 2005 06:55 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
> > Hi,
> >
> > PR21173 and its duplicates are a class of wrong-code and ICE bugs
> > in GCC 4.0.0.
> >
> > In Bugzilla
On Wednesday 04 May 2005 16:22, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?
The patch is called GCC 4.0.
Gr.
Steven
101 - 200 of 1056 matches
Mail list logo
