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:
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
Is a need to build several tables in HTML of the codes (with subcodes).
Each table has an explanation. It's like a roadmap.
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
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
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
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:
Jim Wilson wrote:
> JoseD wrote:
> > @James
> > What do you mean by 16.3.3/3? GCC's version ?
>
> This is a reference to the ISO C standard.
No. It's a reference to the ISO C++ standard. 16.3.3/3
includes the sentence "If the result [of the ## operator] is
not a valid preprocessing token, the
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 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?
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 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]>:
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.
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
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
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
Sergio Giro wrote:
I perceived that many people think that the throw qualifiers, as
described by the standard, are not useful
Yes. But that's not a reason to add a slightly different non-standard
feature that would require people already using standard exception
specifications to rewrite eve
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 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 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
On Tue, Apr 10, 2007 at 05:05:36AM +0800, Mayank Kumar wrote:
> That information was really very helpful. I have been able to localize
the bug. The issue is in the assembler. When I create a object file
using the assembler(as test.s -o test.o), the contents of .rdata which
contains the jump
/* Given X an unsigned of 32 bits, and Y a bool. Try to translate optimizing
*
* Y = X > 2147483647; to Y = ((signed)X) < 0;
* Y = X >= 2147483648; to Y = ((signed)X) < 0;
*
* [ Another optimization is to Y = (X >> 31) ]
*
* The opposite (ELSE):
*
* Y = X <= 2147483647; to Y = ((signe
I'm sorry, i did want to say 2 billions, not 2 millions.
J.C. Pizarro
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
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> /* Given X an unsigned of 32 bits, and Y a bool. Try to translate optimizing
> *
> * Y = X > 2147483647; to Y = ((signed)X) < 0;
> * Y = X >= 2147483648; to Y = ((signed)X) < 0;
> *
> * [ Another optimization is to Y = (X >> 31) ]
As far
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
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
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.
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
On 4/9/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 09 April 2007 21:49, Lawrence Crowl wrote:
>>> The optimization above would be wrong for such machines because
>>> the allocation would be smaller than the requested size.
>>
>> To request a size of ~size_t(0) is to request a size
>> of 0xFFF
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
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
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
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,
10 Apr 2007 10:53:08 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
As far as I can tell, you are recommending that gcc generate a
different code sequence than it currently does. The most helpful
approach you can use for such a suggestion is to open a bug report
marked as an enhancement. Se
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
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
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.
>>
>
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
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 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
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 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
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 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
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
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
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
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
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
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
With respect to this:
Jason Merrill wrote:
Yes. But that's not a reason to add a slightly different non-standard
feature that would require people already using standard exception
specifications to rewrite everything. That's just a non-starter.
Maybe I missed some point: why everything should
On Apr 10, 2007, at 2:06 PM, Sergio Giro wrote:
Maybe I missed some point: why everything should be rewritten?
Let me try again. The standard way to add a new qualifier in g++, is
to add it in an attribute, please do that. The possible responses
are, no, I want to be different, or ok. If
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
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
Mike Stump wrote:
Let me try again. The standard way to add a new qualifier in g++, is
to add it in an attribute, please do that.
OK, I agree. Let's say that a method will be declared as
int method() throw(std::exception) __attribute__((static_exc_check));
(this is intended to have the same mea
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 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
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
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
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.
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
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
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 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
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.
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 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
I prefer the method Jason mentioned of including this functionality as
a form of more strict checking of -Wexception-specs (Or maybe defining
a new warning) as opposed to having an attribute that defines new
semantics.
In the end the two are practically identical. The semantics of the
existing "OL
69 matches
Mail list logo
