Richard Kenner wrote:
Regs_ever_live is the poster child of this. In theory regs_ever_live is
easy, it is just the set of hard registers that are used. In practice
this is a disaster to keep track of because it was only updated
occasionally and its values are randomly changed by the backends
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df
I have posted a new wiki intended to help port maintainers with issues
that may arise with the dataflow branch. The new wiki page can be found
at http://gcc.gnu.org/wiki/DataflowPorting.
Thanks,
Kenny
Andrew MacLeod wrote:
On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
ld.
However, I think that before anyone starts hacking anything, we should
come to a consensus on an overall strategy and implement something
consistent for the entire compiler rather than attack
Paolo Bonzini wrote:
While I agree with you, I think that there are so many things we are
already trying to address, that this one can wait. I think we've
been doing a very good job on large functions too, and I believe that
authors of very large functions are just getting not only what they
Eric Botcazou wrote:
AFAIK not one of the tree optimizers disables itself, but perhaps we
should. The obvious candidates would be the ones that require
recomputation of alias analysis, and the ones that don't update SSA
info on the fly (i.e. require update_ssa, which is a horrible compile
Daniel Jacobowitz wrote:
On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
I think this is probably moot, since I believe that Kenny feels DWARF is
not suitable for reasons other than the abbreviation table issue, but
this is a clever technique.
... for GIMPLE; when
Daniel Jacobowitz wrote:
On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
Given that Mark, and for that matter no one else, did not really push
back, I am pretty much committed not to use dwarf.
Then... what are you going to do about things like types? Invent a new
Diego Novillo wrote:
Kenneth Zadeck wrote on 08/28/06 09:57:
I have not done this because I do not rule the earth. That was not
what I was assigned to do, and I agreed that DWARF3 sounded like a
reasonable way to go. Now that I understand the details of DWARF3, I
have changed my mind
Andrew Pinski wrote:
On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
+#if STUPID_TYPE_SYSTEM
STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
Well it right now it is stupid, this is just a work around anyways until
people fix the type mismatches
Mark Mitchell wrote:
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being compiled. Getting at
those functions that are going
Mark Mitchell wrote:
Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we
Mark Mitchell wrote:
Kenneth Zadeck wrote:
This
will be more cumbersome if we have to keep reloading each object
file's abbrev table just to tear apart a single function in that .o
file. While the abbrev sections average slightly less than %2 of the
of the size of the GIMPLE encoding
Chris Lattner wrote:
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One
Michael Eager wrote:
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
I have only a limited understanding of GIMPLE and LTO
Nick Clifton wrote:
Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved ivopts and
sign issues. Could you send a summary?
Sure:
Diego Novillo wrote:
Kenneth Zadeck wrote on 08/15/06 11:57:
We should be looking at the back end to see where it cannot see what it
needs to see rather than trying to stop getting the middle end code into
a reasonable form.
You're confused. This is a middle-end mis-optimization
David Edelsohn wrote:
Diego Novillo writes:
Diego Agreed. This is a good opportunity for us to design a GIMPLE type
Diego system. Besides the obvious space savings and cleanliness, it is also
Diego needed to remove lang_hooks.types_compatible_p.
And this last statement
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making gimple properly type consistent.
I just wanted to point
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On 8/11/06, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew
Joern Rennecke wrote:
In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write:
depending on what you are doing, you can update the solution in place.
The point of the dataflow talk was not to say that you cannot do
anything incremental, it was to say that there are no good GENERAL
Joern RENNECKE wrote:
Kenneth Zadeck wrote:
I suppose reg-live-at-start / reg-live-at-end information is
actually easier
to maintain during if-conversion that def-use chains.
This is true, certainly in theory, a lot less so in practice.
The way that you order things is this.
while
Joern RENNECKE wrote:
Kenneth Zadeck wrote:
From that description I assumed that you really did care which uses
actually reached which other uses. The reaching uses problem tracks
each use separately. If this isn't what you need then you are free to
use LR which is certainly much cheaper
Joern RENNECKE wrote:
Kenneth Zadeck wrote:
You should do this starting from the dataflow branch. The version of
if-cvt there works as I have mentioned in the previous mail and does not
use propagate block at all.
if-conversion always joins blocks. But cross-jumping merges blocks
Joern RENNECKE wrote:
Kenneth Zadeck wrote:
is it really necessary to do your pass after reg stack. Given that
there is no if conversion that runs after regstack what is your point?
I am talking about cross-jumping after regstack.
I should point out that there are no passes
Joern RENNECKE wrote:
I 've been looking at the problem of converting the struct-equiv code
to use DEF-USE chains
instead of global dataflow information, but I have hit a snag.
We can find local registers as being registers that are defined
somewhere in the examined (partial) block,
and have
Joern RENNECKE wrote:
Kenneth Zadeck wrote:
you can have def-use chains, you can have use-def chains or you can have
both.
It seems like what you are asking for are use-def chains,
No, I want to know if there exists a path from the current *use* of a
register to
some other *use
Steven Bosscher wrote:
On 6/15/06, Joern RENNECKE [EMAIL PROTECTED] wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
-ftree-live-range-split splits live ranges on exit from ssa. This is
on by default, and in fact it is more work to NOT split unrelated live
ranges,
Steven Bosscher wrote:
Hi,
While teaching dce.c on the dataflow-branch to delete noop-moves,
I noticed that most noop moves are produced by reload. It inserts
duplicate insns for some reloads, postreload turns the duplicate
reload into a simple reg-reg move (but the lhs and rhs are the same
Steven, Zdenek
1) single_set is built on top of single_set2.
2) single_set_2 uses REG_UNUSED notes.
3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
I can find no indication that rtl dfa is run here to provide the
information for single_set to produce the correct answer.
Inquiring minds want
Zdenek Dvorak wrote:
Hello,
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see...
Graham Stott wrote:
Andreas,
FWIW I've had successful bootstrap with these checking flags on
x86_64-unknown-lunux-gnu
Graham
My bootstrap was fine also using x86_64-suse-linux-gnu.
Kenny
Andreas Jaeger wrote:
Andrew Pinski [EMAIL PROTECTED] writes:
On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
I'm still seeing this with current
Daniel Berlin wrote:
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc
Andreas Jaeger wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread
Andreas Jaeger wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread
Zdenek Dvorak wrote:
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Eric Botcazou wrote:
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
This is exactly what I did,
-pc-linux-gnu.
Kenny
2005-01-20 Kenneth Zadeck [EMAIL PROTECTED]
* df-scan.c (problem_SCAN): Added NULL reset function.
(df_scan_reset_blocks): Added code to call reset block function
(df_bb_refs_delete) Fixed comment.
(df_insn_refs_delete): Made tolerant of deleting non existent
Steven Bosscher wrote:
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc
Steven, actually the last piece of mail I sent you was a lie.
The bug I fixed is different.
The problem is that between the time that I check my code in an now,
someone changed the representation of BASIC_BLOCK.
lorien:~/gccDFTest/gcc(27) diff basic-block.h ../../gccBaseline/gcc
370c370
Ian Lance Taylor wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
For complete accuracy, there are probably going to be some target
specific registers which need to be handled, unfortunately. For
example, on MIPS, with -mabicalls (which is the default on GNU/Linux),
$25 is live on function
Ian and Honza,
Here is a first draft of the a function to find the set of registers
that are (will) be defined on entry to function. I generated this from
our conversation on chat and by looking around.
This function is necessary in the new version of df because, unlike
flow, we do both
Ian Lance Taylor wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
1) Do you believe that this code could be correct?
Well, no.
You do not have to sugar coat it, I can handle the truth.
2) Most of the paragraphs are protected by either reload_completed or
epilogue_completed
Specifically, advocates of the recent link-time-optimization proposal
[1] may claim that exposing all of the information that DWARF captures
(e.g. about the type system) at link-time is a good thing: it makes it
easier to do specific high-level optimizations, because all of the
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 4.2
What is the rationale for using a stack-based representation rather
than a register-based representation? A infinite register based
solution would seem to map
Mark Mitchell [EMAIL PROTECTED] writes:
http://gcc.gnu.org/projects/lto/lto.pdf
Section 4.2 (Executable Representation) describes the GVM as a stack
machine, and mentions load, store, duplicate, and swap operations.
But it also discusses having registers which correspond to GIMPLE
local
Thanks for woking on this. Any specific reason why using the LLVM
bytecode wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL, the JVM,
LLVM, etc.
It is proven to be stable, high-level enough to
perform any kind of needed optimization,
I will pull a patch together tomorrow. There is currently nothing in
the code for keeping the region stuff up to date as changes are made to
the cfg. For most changes this would not be hard, but for some it is
really hard.
Daniel Berlin wrote:
On Thu, 2005-09-22 at 18:49 -0700, Devang
the splay tree in question is there as part of the type unification.
This is required because our design for combining modules does not unify
the types and this messes up the type escape analysis.
Because of this, the type name must be the key. However, there is the
possibility that doing
Mark Mitchell wrote:
Kenneth Zadeck wrote:
The kludge to handle them is documented in cp/name-lookup.c around
line 670
Ugh.
IMO, the right thing here is that there should be only one
FUNCTION_DECL for a given function, ever, period. Default arguments
are not part of the function in C
I have been trying to cleanup the location where the persistent ipa
information is stored.
The original way that I did this was that I had a field in the var_ann
structure that pointed to the ipa_information.
Now that danny has reorganized the decls, the plan was to just add a
field to the
I was wrong, I misread some debugging output.
Sorry,
kenny
Andrew Pinski wrote:
On Jul 11, 2005, at 8:50 AM, Daniel Berlin wrote:
On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote:
Is this a bug or a feature?
Bug.
where is it occurring?
I want to say the C++ front-end since
I hope to have my code checked in today.
Look in ipa-reference.c
Kenny
Daniel Berlin wrote:
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
Hello,
Is
Mark Mitchell wrote:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(b.a);
}
does the compiler have to assume that g may access the parts of
b outside of a. If the compiler can see the body of g than
it may be able to figure out
The build gets partially thru the stage2 and then crashes when trying to
compile most of the back end in one step with the following message:
gcc: cannot specify -o with -c or -S and multiple compilations
This same step works fine on my pentium (suse 9.2) and darwin machines.
I am compiling
Thanks, for looking into it.
kenny
Andrew Pinski wrote:
On Feb 18, 2005, at 11:50 AM, Kenneth Zadeck wrote:
The build gets partially thru the stage2 and then crashes when trying
to compile most of the back end in one step with the following message:
gcc: cannot specify -o with -c or -S
501 - 557 of 557 matches
Mail list logo
