On 12 July 2007 05:21, [EMAIL PROTECTED] wrote:
>> On 7/10/07, [EMAIL PROTECTED] writes:
>>> On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: You haven't
>>> explained what advantages CIL's IR has over GIMPLE. I thought it was
>>> well explained on page: _http://hal.cs.berkeley.edu/c
>On 7/10/07, [EMAIL PROTECTED] writes:
>>On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>You haven't explained what advantages CIL's IR has over GIMPLE.
>>I thought it was well explained on page:
>>_http://hal.cs.berkeley.edu/cil/cil001.html_
(http://hal.cs.berkeley.edu/cil/cil00
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time,
[EMAIL PROTECTED] writes:
>On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
>> writes:
[EMAIL PROTECTED] writes:
> Please look at this page:
> _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html_
> (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir.html)
That tells me about the MLRISC IR, but it doesn't tell me what
significant advantages it has over GIMPLE.
>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time,
[EMAIL PROTECTED] writes:
>On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
>> writes:
>> >This page http://deputy.cs.berkeley.edu/ has a link
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
writes:
>This page http://deputy.cs.berkeley.edu/ has a link to this document
http://hal.cs.berkeley.edu/cil/
>which describes a means to obtain three-address code
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
writes:
>This page http://deputy.cs.berkeley.edu/ has a link to this document
http://hal.cs.berkeley.edu/cil/
>which describes a means to obtain three-address code here
http://hal.cs.berkeley.edu/cil/ext.html#toc24 .
On 7/7/07 7:04 AM, [EMAIL PROTECTED] wrote:
> If you ask nicely they would let you use CIL's code in GCC ;) .
Any specific reasons why we should? Better memory savings? Faster
processing? It's not clear from your message what the advantages would
be (ignoring the fact that their implementation
On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])
>:
>Following up on the recent discussion about GIMPLE tuples
>(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ),
>2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])
>:
>Following up on the recent discussion about GIMPLE tuples
>(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ), we have summarized
>our main ideas and implementation p
Dave Korn wrote:
Using a delta is even better than an XOR, because it remains constant when
you relocate the data.
Could someone explain why we are re-inventing VAX instructions here ?
[ OK, 1/2 :-) ]
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG
On 11 April 2007 17:05, Andi Kleen wrote:
>>> Adding a xor is basically free and much cheaper than any cache miss
>>> from larger data structures.
>>
>> Using a delta is even better than an XOR, because it remains constant
>> when you relocate the data.
>
> You can xor deltas as well as pointe
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 obvious way to make the proposed tuples position independ
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 obvious way to make the proposed tuples position independent would
>>> be to use array offsets rather than pointers.
>>
>> I su
If you go this way (and require special GC/debugger support) you
could as well xor next/prev too and save another field.
Adding a xor is basically free and much cheaper than any cache miss
from larger data structures.
The only thing that wouldn't work is that when you have a pointer
to an arbi
On Tue, Apr 10, 2007 at 06:53:07PM -0700, Mark Mitchell wrote:
> Self-relative, not PC-relative, right?
Yes. I tend to use the terms interchangably, since if you're generating
object files, the relocation is still named "pc-relative".
r~
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
Richard Henderson wrote:
> 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, that we make
> the referenc
Diego Novillo <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote on 04/10/07 21:19:
| > On Tue, Apr 10, 2007 at 08:48:27PM -0400, Diego Novillo wrote:
| >> Sure, but things will be different if/when the operands stop being 'tree'.
| >
| > We'll burn that bridge when we come to it.
|
| Works f
Richard Henderson wrote on 04/10/07 21:19:
> On Tue, Apr 10, 2007 at 08:48:27PM -0400, Diego Novillo wrote:
>> Sure, but things will be different if/when the operands stop being 'tree'.
>
> We'll burn that bridge when we come to it.
Works for me.
On Tue, Apr 10, 2007 at 08:48:27PM -0400, Diego Novillo wrote:
> Sure, but things will be different if/when the operands stop being 'tree'.
We'll burn that bridge when we come to it.
It's possible to parameterize the fold-const even further.
One passes in void* instead of tree, and have a set of
On Tue, Apr 10, 2007 at 05:49:03PM -0700, Ian Lance Taylor wrote:
> But fold_binary takes trees as parameters. How are you thinking of
> calling it?
The operands of gimple statements are still trees.
Very simple trees, mind, but trees.
r~
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, that we make
the references be pc-relative. So something li
Ian Lance Taylor wrote on 04/10/07 20:49:
> I'm having a hard time seeing it. fold_build2 calls fold_binary; I
> agree that if we can handle fold_binary, we can handle fold_build2.
> But fold_binary takes trees as parameters. How are you thinking of
> calling it?
the gimple version of z = x + y
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2007 at 10:53:19AM -0700, Ian Lance Taylor wrote:
> > As you know, we have a lot of basic optimizations in fold-const.c that
> > operatee on trees. We also have a lot of basic optimizations in
> > simplify-rtx.c that operate on RTL.
Richard Henderson wrote on 04/10/07 20:30:
> Perhaps I misunderstood what Diego was proposing, but I
> would have thought the subcode would continue to be the
> tree PLUS_EXPR, and not a GS_PLUS something.
Yes.
> With that, build_foldN does essentially what we want,
> without having to regenera
On Tue, Apr 10, 2007 at 10:53:19AM -0700, Ian Lance Taylor wrote:
> As you know, we have a lot of basic optimizations in fold-const.c that
> operatee on trees. We also have a lot of basic optimizations in
> simplify-rtx.c that operate on RTL. These sets of optimizations are
> independent implemen
On Tue, Apr 10, 2007 at 05:23:55PM -0400, Andrew MacLeod wrote:
> We'd also be able to "linearize" things when we write it out... ie,
> flatten out the linked lists of instruction so they are all continguous
> indexes, tables etc. this would make it compact and when its read in, we
> might even see
Ian Lance Taylor wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
>> Following up on the recent discussion about GIMPLE tuples
>> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
>> our main ideas and implementation proposal in the attached document.
>>
>> This should be e
On 4/10/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 4/10/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Here is the quick patch (thanks to the work done for gimple tuple)
> which does this, removes the unneeded type from phi nodes. I have not
> tested it except for a quick test on some small
On Tue, 2007-04-10 at 15:02 -0400, Diego Novillo wrote:
> Ian Lance Taylor wrote on 04/10/07 14:13:
> > I would like us to seriously think about this approach. Most of the
> > details would be hidden by accessor macros when it comes to actual
> > coding. The question is whether we can tolerate s
2007/4/10, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
Personally, just stick with the double linked lists, be it via pointers
or array index. Any of these other suggestions either complicate the
algorithms or slow down traversal or both to save that word of memory
and slow down the initial imple
On Tue, 2007-04-10 at 16:03 -0400, Diego Novillo wrote:
> Dave Korn wrote on 04/10/07 15:39:
>
> > Reverse-traversing an array really isn't all that painful or slow!
>
> Instructions are not laid out in an array. Insertion and removal is
> done constantly. It would be very expensive to use ar
On 10 April 2007 21:03, Diego Novillo wrote:
> Dave Korn wrote on 04/10/07 15:39:
>
>> Reverse-traversing an array really isn't all that painful or slow!
>
> Instructions are not laid out in an array. Insertion and removal is
> done constantly. It would be very expensive to use arrays to rep
2007/4/10, Dave Korn <[EMAIL PROTECTED]> wrote:
On 10 April 2007 20:02, Diego Novillo wrote:
>> The obvious way to make the proposed tuples position independent would
>> be to use array offsets rather than pointers. This has the obvious
>> disadvantage that every access through a pointer requir
Andrew Pinski wrote on 04/10/07 16:04:
> On 4/10/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> Here is the quick patch (thanks to the work done for gimple tuple)
>> which does this, removes the unneeded type from phi nodes. I have not
>> tested it except for a quick test on some small testcases
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
On 4/10/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Here is the quick patch (thanks to the work done for gimple tuple)
which does this, removes the unneeded type from phi nodes. I have not
tested it except for a quick test on some small testcases so there
might be more places which use TREE_CHA
Dave Korn wrote on 04/10/07 15:39:
> Reverse-traversing an array really isn't all that painful or slow!
Instructions are not laid out in an array. Insertion and removal is
done constantly. It would be very expensive to use arrays to represent
basic blocks. Insertions and deletions are all to
On Tue, 2007-04-10 at 20:39 +0100, Dave Korn wrote:
> On 10 April 2007 20:02, Diego Novillo wrote:
>
> >> The obvious way to make the proposed tuples position independent would
> >> be to use array offsets rather than pointers. This has the obvious
> >> disadvantage that every access through a po
Daniel Berlin wrote on 04/10/07 15:18:
> There is no need for the addresses_taken bitmap, it's a waste of space.
Awesome. I was going to check, but I forgot. I did check the
stmt_makes_clobbering_call and that one is also write-only.
> Neither of these really needs it, and i have a patch to re
On 10 April 2007 20:02, Diego Novillo wrote:
>> The obvious way to make the proposed tuples position independent would
>> be to use array offsets rather than pointers. This has the obvious
>> disadvantage that every access through a pointer requires an
>> additional memory reference. On the othe
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote on 04/10/07 13:53:
> I seem to recall that at one point somebody worked on a gensimplify
> program or something like that. Would it make sense to revive that
> approach, and use it to generate simplifiers for trees, GIM
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementati
Ian Lance Taylor wrote on 04/10/07 14:13:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
>> Following up on the recent discussion about GIMPLE tuples
>> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
>> our main ideas and implementation proposal in the attached document.
>>
>
2007/4/10, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Tue, 2007-04-10 at 19:54 +0200, J.C. Pizarro wrote:
> Can i remove the word "prev"?
> Thanks to "bb", i can traverse the short list of
> the small basic block getted from its hashtable.
Do you mean implement this as a single linked list and
On 4/9/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Also I noticed in your pdf, you have "PHI NODE" as 12%, we can improve
the memory usage for this statement by removing the usage of
TREE_CHAIN/TREE_TYPE, so we can save 4/8 bytes for those 12% without
doing much work. I can send a patch in the
Mike Stump <[EMAIL PROTECTED]> writes:
> On Apr 10, 2007, at 10:53 AM, Ian Lance Taylor wrote:
> > I seem to recall that at one point somebody worked on a gensimplify
> > program or something like that. Would it make sense to revive that
> > approach, and use it to generate simplifiers for trees,
Ian Lance Taylor wrote on 04/10/07 13:53:
> I seem to recall that at one point somebody worked on a gensimplify
> program or something like that. Would it make sense to revive that
> approach, and use it to generate simplifiers for trees, GIMPLE, and
> RTL, to avoid triplification of these basic
Diego Novillo <[EMAIL PROTECTED]> writes:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the implementation
On Tue, 2007-04-10 at 19:54 +0200, J.C. Pizarro wrote:
> Hi Diego Novillo
>
> Your "Tuple representation" of the GIMPLE instructions was:
> HEADER:
> code16 bits
> subcode 16bits
> nextword
> prevword
> bb word
> locus word
> block wor
On Apr 10, 2007, at 10:53 AM, Ian Lance Taylor wrote:
I seem to recall that at one point somebody worked on a gensimplify
program or something like that. Would it make sense to revive that
approach, and use it to generate simplifiers for trees, GIMPLE, and
RTL, to avoid triplification of th
Ian Lance Taylor wrote on 04/10/07 13:53:
> Don't you need four operands for a conditional move? Is that what you
> meant?
Ah, yes. The two comparison operands and the two assignment values.
Hi Diego Novillo
Your "Tuple representation" of the GIMPLE instructions was:
HEADER:
code16 bits
subcode 16bits
nextword
prevword
bb word
locus word
block word
BODY:
OP0 word
..
OPN word
I've a little idea,
Can i remove
Diego Novillo <[EMAIL PROTECTED]> writes:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the implementation
Diego Novillo <[EMAIL PROTECTED]> writes:
> J.C. Pizarro wrote on 04/10/07 02:08:
>
> > However, they've appeared the "conditional moves" to don't jump
> > and consecuently to reduce the penalization of the conditional jump.
>
> We already have conditional moves. Notice that subcodes for GS_ASS
On Tue, 2007-04-10 at 00:49 -0400, Diego Novillo wrote:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the im
Richard Guenther wrote on 04/10/07 11:02:
> Well, we now have a tcc_comparison for example - is the gimple statement code
> something like that? Or will the grouping of gimple statement codes
> to code classes
> persist? If we were able to encode the class directly in the gimple
> statement we
>
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote on 04/10/07 10:45:
> On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> Steven Bosscher wrote on 04/10/07 02:43:
>>> I don't really like the idea for promoting subcodes to first-level
>>> codes, like you do for GS_CO
Richard Guenther wrote on 04/10/07 10:45:
> On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> Steven Bosscher wrote on 04/10/07 02:43:
>>> I don't really like the idea for promoting subcodes to first-level
>>> codes, like you do for GS_COND NE and EQ. Looks complicated and
>>> confusing to me
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote on 04/10/07 02:43:
> On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> Thoughts/comments on the proposal?
>
> This looks a lot like the RTL insn!
>
> For locus, you can use just an "int" instead of a word if you use
2007/4/10, Diego Novillo <[EMAIL PROTECTED]> wrote:
J.C. Pizarro wrote on 04/10/07 10:24:
> By example, worth weigths, use's frecuencies, statistical data, ... of GIMPLE.
> To debug the GIMPLE too.
That's kept separately. Pointer maps, hash tables...
> How you debug the failed GIMPLE?
Lots o
2007/4/10, Diego Novillo <[EMAIL PROTECTED]>:
J.C. Pizarro wrote on 04/10/07 08:17:
> Is a need to build several tables in HTML of the codes (with subcodes).
> Each table has an explanation. It's like a roadmap.
Hmm, what?
Forget it, it's not so important.
J.C. Pizarro wrote on 04/10/07 10:24:
> By example, worth weigths, use's frecuencies, statistical data, ... of GIMPLE.
> To debug the GIMPLE too.
That's kept separately. Pointer maps, hash tables...
> How you debug the failed GIMPLE?
Lots of debug_*() functions available. You also use -fdump-
2007/4/10, Diego Novillo <[EMAIL PROTECTED]> wrote:
More debug information? What debug information are you looking for?
By example, worth weigths, use's frecuencies, statistical data, ... of GIMPLE.
To debug the GIMPLE too.
How you debug the failed GIMPLE?
J.C. Pizarro
J.C. Pizarro wrote on 04/10/07 08:17:
> Is a need to build several tables in HTML of the codes (with subcodes).
> Each table has an explanation. It's like a roadmap.
Hmm, what?
Steven Bosscher wrote on 04/10/07 02:43:
> On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> Thoughts/comments on the proposal?
>
> This looks a lot like the RTL insn!
>
> For locus, you can use just an "int" instead of a word if you use the
> same representation for locations as we do for
J.C. Pizarro wrote on 04/10/07 02:08:
> However, they've appeared the "conditional moves" to don't jump
> and consecuently to reduce the penalization of the conditional jump.
We already have conditional moves. Notice that subcodes for GS_ASSIGN
have the same meaning as they do today. GS_ASSIGN:
J.C. Pizarro wrote on 04/10/07 01:24:
> 1. Are there fields for flags, annotations, .. for special situations?
Yes, some instructions have no sub-codes and will use the subcodes field
for flags. Annotations and such will be discouraged as much as
possible. If an attribute is very frequently use
Andrew Pinski wrote on 04/10/07 01:43:
> Yes clobbers for asm are strings and don't really need to be full
> trees. This should help out more. though it does make it harder to
> implement.
Hmm, could be. The problem is that __asm__ are so infrequent that I'm
not sure it's worth the additional
Richard Guenther wrote on 04/10/07 08:01:
> It looks decent, but I also would go one step further with location
> information and
> PHI node "canonicalization".
What would be the "step further" for PHI nodes? We haven't really left
anything to spare inside GS_PHI.
For insn locators, the idea is
Is a need to build several tables in HTML of the codes (with subcodes).
Each table has an explanation. It's like a roadmap.
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementati
I don't really like the idea for promoting subcodes to first-level
codes, like you do for GS_COND NE and EQ. Looks complicated and
confusing to me. What is the benefit of this?
Fully agreed with Steven (also on the locators bit).
Paolo
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Thoughts/comments on the proposal?
This looks a lot like the RTL insn!
For locus, you can use just an "int" instead of a word if you use the
same representation for locations as we do for RTL (INSN_LOCATOR). You
mention this step as "straigh
The "conditional jumps" are sometimes bad.
However, they've appeared the "conditional moves" to don't jump
and consecuently to reduce the penalization of the conditional jump.
I've the idea of combining GS_ASSIGN... and GS_COND... to give these
following 6 new GIMPLE instructions:
GS_ASSIGN_CON
On 4/9/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementatio
2007/4/10, Diego Novillo <[EMAIL PROTECTED]>:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementation goin
78 matches
Mail list logo
