I've been solving conflicts left and right and ran into the same set
of problems Diego describes independently.
What's up with cbsi_last()/bsi_last(), and the rest of the functions
that have been duplicated? We really shouldn't be changing APIs here,
and if we absolutely need more than one routin
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes:
> are gimplify.c for all the conversion to GIMPLE, tree-cfg.c for the
> building of the CFG and omp-low.c for the conversion into Low
> GIMPLE.
Actually, gimple-low.c. omp-low.c is only for the OpenMP lowering.
> The test there is sort of hack, I would just remove it at this stage and
> we can work out better fix for that testcase later. I hope that with my
> plans for declaration merging pass we can get round such weird side
> effects of in place declaration replacement.
Will do.
How about all the oth
Hi Jan.
What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
/* ??? It is possible to create extern inline function and later using
weak alias attribute to kill its body. See
gcc.c-torture/compile/2009-1.c */
if (!DECL_SAVED_TREE (decl))
> I have often been confused with the 'GS' prefix we have throughout the
> API. It's confusing as we seem to have two different things (GS and
> GIMPLE).
>
> I would like to propose that we rename all the 'gs' and 'GS' prefixes to
> 'GIMPLE'. That would mean renaming files, data structures and v
On Wed, Jun 27, 2007 at 11:09:26AM -0400, Diego Novillo wrote:
> On 6/26/07 4:08 PM, Diego Novillo wrote:
>
> > But, first, I'd like to know what folks think about this. Would it be
> > generally useful for us to have the IL data structures auto-generated
> > this way? I can see the benefits in
...as of rev 125166.
No surprises.
Aldy
> >The pretty print routines could definitely use a lot of cases
> >(dump_gimple_stmt), and the work is very self contained.
>
> So I took a look at this the other day, and you seem to have at least
> every case that has accessors.
>
> Did you want me to write accessors for the other types and th
Hi Dan. Hi folks.
People (ok, so it was Dan) had asked if there was anything they could do to
help the tuples effort.
The pretty print routines could definitely use a lot of cases
(dump_gimple_stmt), and the work is very self contained.
There is also the constructors and accessors for the IR.
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wiki/tuples
Aldy
ild/gencheck.o): Add gs.def.
Index: gimple-ir.c
===
--- gimple-ir.c (revision 0)
+++ gimple-ir.c (revision 0)
@@ -0,0 +1,154 @@
+/* Gimple IR support functions.
+
+ Copyright 2007 Free Software Foundation, Inc.
+ Contributed by Al
> > +/* A sequences of gimple statements. */
> > +#define GS_SEQP_FIRST(S) (S)->first
> > +#define GS_SEQP_LAST(S)(S)->last
> > +#define GS_SEQ_FIRST(S)(S).first
> > +#define GS_SEQ_LAST(S) (S).last
>
> Why do you have both of these?
Most places in the gimpl
ree, tree *);
Index: gsstruct.def
=======
--- gsstruct.def(revision 0)
+++ gsstruct.def(revision 0)
@@ -0,0 +1,55 @@
+/* This file contains the definitions for the gimple IR structure
+ enumeration used in GCC.
+
+ Copy
> There are a lot of us that are happy to devote time and people
> resources to helping you with this (both design and implementation),
> so if you feel like you don't have time to go look at other IR's or
> something, please let us help :)
That would be great, especially the bit about looking at
Hi guys!
I've been having sporadic conversations with both Diego and Rth regarding
tuples, and I wanted to sum up, and get others' opinions.
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actu
> "DJ" == DJ Delorie <[EMAIL PROTECTED]> writes:
>> Oh, I get it now. No, there is no reason for the duplication between
>> minmax_operator and the insn itself. You should be able to remove the
>> tests from minmax_operator. I wonder why they are there at all?
> This, then?
Ok.
Hi folks.
I have just merged gimple-tuples-branch into mainline.
The memory improvements as of last night are as follows:
-O0: 0.260409%
-O1: 0.828741%
-O2: 0.826724%
These are averages in analyzing about 8000 functions taken from Diego's .i
sandbox. I used the same met
I have finished a merge from mainline @ 119445 into the tuples branch. It
bootstraps and exhibits only one regression in libjava:
FAIL: PR27908 -O3 execution - source compiled test
This has been around forever, I've just been lazy and hadn't figured out
how to run java tests individually. Tom T
> Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
> My vote is to merge into mainline sooner rather than later. However, it
> is a big patch and affects just about every module in the compiler, so I
> wouldn't want to barge in without getting some consensus first.
I agree with you and Mark.
What I'd like to do next is:
1. Merge mainline into
Hi folks.
Now that the branch is bootstrapping with no regressions (C and C++ anyhow),
I have run some memory benchmarks to make sure we're on the right path.
So far I have only implemented GIMPLE_MODIFY_STMT which is the tuples
counterpart of MODIFY_EXPR.
To compare memory usage, I forced a gar
the
+ current notion of treating everything as a tree
+ (http://gcc.gnu.org/wiki/tuples";>
+ http://gcc.gnu.org/wiki/tuples).
+ This branch is maintained by Aldy Hernandez and will be routinely merged
+ with mainline. Patches and discussion on this branch should be marked with
+ the
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
> Please add your project page to the bottom of:
>http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning
I just added a page for the tuples work.
Aldy
> I think this patch may have fried your brain slightly:
>
> (get_modify_stmt_operands): Rename from get_modify_stmt_operands.
Definitely! Good catch. Fixed.
Hi folks!
You might have thought I've been drinking pi~na coladas in the sun, but
alas, I've been beating my head mercilessly with this gimple tuple business.
What I have so far is getting so big (280k), it's getting hard to manage and
keep track of things in my brain. What do you guys think abo
Hi folks.
Under Diego's loving whip, I've been taking a look at GIMPLE tuples, and
have come up with a possible layout for the data structures representing
the tuples. It's a mix between what Mark and Diego's originally suggested
along with a few other things ;-).
Still missing are labels and gi
> losing a slight missed optimization on the tree level.
Yay, exactly what I'm trying to fix. Glad you agree.
Aldy
> Well, it's written to only in this testcase. Can you post a more complete
> one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(&t);
}
> I should also mention on the mainline, we get the decomposing for the
> orginal testcase which means this is a bug only on the MEM-SSA branch.
No we don't. Look at the actual testcase I posted. This is a bug on
mainline.
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
we end up with:
# t_2 = V_MU
On Tue, Feb 14, 2006 at 06:08:42PM -0800, Mark Mitchell wrote:
> Aldy Hernandez wrote:
>
> > Do we keep a hash of functions that have been written out somewhere?
>
> Not to my knowledge.
>
> > I'd hate to walk the entire hash table each time we write out a func
> You could combine the two ideas: a global hash table of types used in
> casts, where each entry had a list of functions using those types. That
> should take up no more storage than the per-function vectors. Then,
> you'd have to walk the entire hash table, writing out each type for
> which at
Hi folks.
Sorry I've taken so long on this. There was this marriage thing in
which I was a protagonist, and it's gotten me way off balance :).
I've been chasing my tail on implementation details. I was hoping
someone could give me a few hints.
>> A solution that comes to mind is to have the f
> I think the line should be
> + ms1 | S F B p g bd
Argh, I misread "does not" for "does".
Ok, committing the following.
Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision
On Thu, Dec 01, 2005 at 04:18:20PM +0100, Steven Bosscher wrote:
> Hi Aldy,
>
> The MS1 backend is not listed in http://gcc.gnu.org/backends.html.
> Could you please add it?
This is what I have.
Nathan, how does this look to you?
Index: backends.html
BTW, here is the original thread I had started:
http://gcc.gnu.org/ml/gcc/2003-04/msg00695.html
> > There was a thread discussing all this, when I was interested in doing
> > the work. I mailed rms directly, and he said it was ok to use the
> > glibc bits in gcc regardless of the LGPL/GPL dispar
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Henderson wrote:
>> The glibc bits handle ieee quad format, whereas I don't believe
>> that Torbajorn's does. I don't recall if Torbajorn's code allows
>> for emulation of all rounding modes or exception bits.
> I believe i
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
> On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
>> RTH is listed as the author of a lot of those bits, so perhaps he knows
>> more?
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torba
On Thu, Nov 17, 2005 at 10:24:21PM -0800, Mark Mitchell wrote:
> Richard Henderson wrote:
>
> > A solution that comes to mind is to have the front-end add dummy
> > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
> > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and
> A stronger case for changing this would be that gcc version
> n-1 didn't warn. As discussed elsewhere, some modicum of
> stability in warnings is desirable from the user's perspective.
> I don't know whether or not this applies in this case.
Well, as I mentioned in the PR, macro writers can wra
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
use it. I see two alternative
Hi folks.
In this PR we are emitting a "value computed is not used" warning for the
following code (via some fancy macro expansion in the Linux kernel):
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile un
More questions wrt this PR.
The problem here is in reshape_init_array_1. Ever since we made
max_index_cst and index *unsigned* HOST_WIDE_INT, we are causing the
loop over initializers to wrongly iterate when we have zero sized arrays.
Since on a zero sized array, we have "tree max_index" set to:
Hi folks.
The code below is ICE-ing in C++:
typedef struct {
unsigned char dir;
int data[];
} AiDefaultRailBlock;
static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
According to our docs, this is valid under flexible arrays:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-L
On Wed, May 11, 2005 at 07:44:46PM -0400, Aldy Hernandez wrote:
> Joern.
>
> My combined tree is acting up, so I haven't tested a full build of
> ppc-eabi*, but this fixes the -mlittle problem.
>
> Let me know how it goes.
This patch fixed Joern's problems (well, t
Joern.
My combined tree is acting up, so I haven't tested a full build of
ppc-eabi*, but this fixes the -mlittle problem.
Let me know how it goes.
Aldy
* config/rs6000/sysv4.opt (mlittle): Handle.
* config/rs6000/rs6000.c (rs6000_handle_option): Set
target_flags_explici
> Some experimentation shows that the assembler from the two dates behaves
> the same,
> and eabi.S is identical, but the preprocessed source files differ. cc1
> used to define
> _RELOCATABLE, but it does not any more.
The problem is that target_flags_explicit was not being set on the
options t
On Tue, May 10, 2005 at 06:54:12PM +0100, Joern RENNECKE wrote:
> Between 20050505 and 20050510, the ppc-eabisim configuration was broken.
> I'm seeing this error:
I'll take a look.
Aldy
Hi folks.
All mail addressed to me from Apr-3 to Apr-10 was not delivered. I was
having problems with my mail setup. Please resend.
My apologies for reporting this so late; I've been sequestered at
customer sites with no internet for the past week after my vacation :-(.
Cheers.
Aldy
> A back end for a target architecture in GCC has the following parts:
> [...]
> @item
> An optional @[EMAIL PROTECTED] file in the @[EMAIL PROTECTED]
> directory, containing a list of target-specific options. You can also
> add other option files using the @code{extra_opti
Hi Richard.
I've been converting the ppc options to use the .opt machinery, and
am confused as to how to approach subtargets.
What's the deal with these?
I need options only for certain subtargets. For example, aix.h has
some options that should not be available by other targets.
I don't see a
Someone pointed out lack of documentation for the e500 cpu. Committing
to mainline, 4.0, 3.4, and 3.4-e500-branch.
Phew.
Aldy
* doc/invoke.texi: Add 8540 to list of cpus in rs6000 cpu section.
Index: doc/invoke.texi
===
RCS
201 - 252 of 252 matches
Mail list logo
