> 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
> I think something like
>
> struct gimple_statment_base
> {
> enum gimple_stmt_code code : 8;
> unsigned int subcode : 24;
> source_locus locus;
> tree block;
Just jumping late into the debug info discussion, RTL locators are
combining TREE blocks and source_locuses into sing
On 3/29/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
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
actual separation between tuples and trees. This business of "this is
a tree, but not real
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Aldy Hernandez <[EMAIL PROTECTED]> writes:
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR,
On 3/29/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote:
> On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >Why will expressions have location? It seems to me preferable to save
> >the memory. After a fe
On Thu, Mar 29, 2007 at 09:38:02PM -0700, Ian Lance Taylor wrote:
> Provided we keep locations on statements, specifically including
> GIMPLE_MODIFY_EXPR, does it really help us to keep locations on
> expressions within statements in optimized code? What could the
> debugger do with that informati
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > Why will expressions have location? It seems to me preferable to save
> > the memory. After a few optimization passes many of the expressions
> > have no location anyhow.
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote:
> On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >Why will expressions have location? It seems to me preferable to save
> >the memory. After a few optimization passes many of the expressions
> >have no lo
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location anyhow.
And I know from past experiences, that this is really a
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> 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
> actual separation between tuples and trees. This business of "this is
> a tree, but not really",
On Thu, Mar 29, 2007 at 04:16:35PM -0400, Aldy Hernandez wrote:
> * By extension, we will also need:
>
> typedef struct gimple_expression_d { ... } * gimple_expr;
>
> For example, PLUS_EXPR, etc. These will have location, btw.
> Something like:
>
> gimple
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
12 matches
Mail list logo
