Hello,
> > > This looks like a better approach. How would we do your step 1? We
> > > have var_ann and tree_ann in addition to stmt_ann. Shall we put a
> > > type field at the beginning of tree_statement_list_node+stmt_ann_d so
> > > that an annotation node can identify itself? (Since all thes
Hi Zdenek,
> > This looks like a better approach. How would we do your step 1? We
> > have var_ann and tree_ann in addition to stmt_ann. Shall we put a
> > type field at the beginning of tree_statement_list_node+stmt_ann_d so
> > that an annotation node can identify itself? (Since all these tr
On Mon, 2005-04-25 at 20:32, Kazu Hirata wrote:
> Hi Adnrew,
> This looks like a better approach. How would we do your step 1? We
> have var_ann and tree_ann in addition to stmt_ann. Shall we put a
> type field at the beginning of tree_statement_list_node+stmt_ann_d so
> that an annotation node
Hello,
> > Then why not simply shorten this to:
> >
> > 1) put stmt annoation directly in the tree_statement_list_node
> >
> > 2) replace stmt_ann_t pointer in stmt with a pointer to its BSI, or the
> > tree_statement_list_node. This makes bsi_from_stmt O(1) immediately.
> >
> > 3) all stmts n
Hi Adnrew,
> > No, I would like to remove stmt_ann_t pointer from the stmt node, but
> > not yet. All I want to do in this project is to put
> > tree_statement_list_node and stmt_ann_d next to each other in memory
> > while doing necessary adjustments in the compiler. Nothing more than
> > that.
On Mon, 2005-04-25 at 19:01, Kazu Hirata wrote:
> Hi Andrew,
> No, I would like to remove stmt_ann_t pointer from the stmt node, but
> not yet. All I want to do in this project is to put
> tree_statement_list_node and stmt_ann_d next to each other in memory
> while doing necessary adjustments in
Hi Andrew,
> OK, let me word it a different way. What is create_stmt_ann (stmt)
> going to do with the annotation it creates? You are moving the
> stmt_ann_t pointer from the stmt node to the tree_statement_list_node...
> so there will be nothing in the stmt node to attach the annotation to
> lik
On Mon, 2005-04-25 at 17:55, Kazu Hirata wrote:
> Hi Andrew,
>
> > How is the get_stmt_ann (stmt) going to work from the caller of
> > create_ssa_artificial_load_stmt() when it goes to look at the operands
> > for its new "stmt"?
>
> I am going to replace that particular call to get_stmt_ann w
Hi Andrew,
> How is the get_stmt_ann (stmt) going to work from the caller of
> create_ssa_artificial_load_stmt() when it goes to look at the operands
> for its new "stmt"?
I am going to replace that particular call to get_stmt_ann with a call
to create_stmt_ann. The beginning of create_ssa_ar
Hi Zdenek,
> Once this is done, I would like to start working on moving gimple out of
> trees to the "flat" structure.
Very cool! I am glad you'll be working on this!
Kazu Hirata
Hello,
> > o One step closer to a flat statement structure (or a tuple form if
> > you like). It's a bit silly that we have GIMPLE, but we still do
> > not have a flat structure.
on a side note, I am currently working on cleaning up gimplification
(mostly to enable embedding of simple and fa
On Mon, 2005-04-25 at 14:37, Kazu Hirata wrote:
> Hi Andrew,
>
> > well, there isnt a tree_statement_list_node right... DOM simply has an
> > expression, and we end up calling create_stmt_ann. I guess you would
> > have to create a completely detached stmt_list node for this case. what
> > are y
Hi Andrew,
> well, there isnt a tree_statement_list_node right... DOM simply has an
> expression, and we end up calling create_stmt_ann. I guess you would
> have to create a completely detached stmt_list node for this case. what
> are you planning to have create_stmt_ann do?
I am thinking abou
On Mon, 2005-04-25 at 12:00, Kazu Hirata wrote:
> Hi Andrew,
> > I believe DOM uses the routine to create a dummy expression for a store
> > which looks like a load. This load is then entered into the equivalency
> > tables such that the store of the expression also shows up as a load
> > allowing
Hi Andrew,
> > I might need your help later as a loop optimizer expert. I just found
> > yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> > a statement proper is linked to a basic block. Specifically, it
> > creates a statement, attaches a stmt_ann, and puts it on edge.
Hi Andrew,
> It will also involve figuring out what to do with DOM, which has some
> hacks via a call to create_ssa_artficial_load_stmt() which causes a
> non-stmt to have a stmt annotation and operands created for it. I've
> been bugging Diego to replace the parts of DOM which use this so we can
On Mon, 2005-04-25 at 11:32, Kazu Hirata wrote:
> I might need your help later as a loop optimizer expert. I just found
> yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> a statement proper is linked to a basic block. Specifically, it
> creates a statement, attaches a stm
Hi Zdenek,
> guessing from (*) below, you probably just forgot to mention that it also
> involves changing SSA_NAME_DEF_STMT to point to the
> tree_statement_list_node rather than the statement itself,
> otherwise there is no way how to get the
> annotation for SSA_NAME_DEF_STMT (name)?
I am not
On Mon, 2005-04-25 at 04:48, Zdenek Dvorak wrote:
> Hello,
>
> > I am thinking about merging stmt_ann_d into tree_statement_list_node.
> >
> > Background
> > --
> >
> > tree_statement_list_node is a linked list node defined like so
> >
> > struct tree_statement_list_node {
> > struct t
On Monday 25 April 2005 10:48, Zdenek Dvorak wrote:
> > the CFG inliner will hit bsi_for_stmt hard.
>
> This is just because CFG inliner is badly written; Honza has already
> fixed that in his private tree.
The CFG inliner is badly written, sure, but the problem is before
that. It's finding the
Hello,
> I am thinking about merging stmt_ann_d into tree_statement_list_node.
>
> Background
> --
>
> tree_statement_list_node is a linked list node defined like so
>
> struct tree_statement_list_node {
> struct tree_statement_list_node *prev;
> struct tree_statement_list_node *next
21 matches
Mail list logo
