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
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
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
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
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
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
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
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
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 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 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
"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:
> 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
I'm sorry, i did want to say 2 billions, not 2 millions.
J.C. Pizarro
/* 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
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
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
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
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
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
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
69 matches
Mail list logo
