This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [CFT, try 8] Emulated tls rewrite

On 07/20/2010 08:53 AM, Richard Guenther wrote:
> +  /* For normal statements, we let update_stmt do its job.  But for phi
> +     nodes, we have to manipulate the immediate use list by hand.  */
> +  if (wi.changed)
> +    {
> +      gcc_assert (TREE_CODE (pd->def) == SSA_NAME);
> +      link_imm_use_stmt (&pd->imm_use, pd->def, phi);
> +    }
> if you can use SET_USE here it will do the immediate-use handling
> for you.  Might not be very convenient here, so probably the above
> is ok.

Yeah, I looked at that after you mentioned it the other day,
but since I already pulled out the phi_arg_t to make the 
scanning a bit easier it's just as easy to go ahead with
the one line to perform the link here.

> +      /* If the block is empty, of course we use it.  */
> +      gsi = gsi_last_bb (src);
> +      if (gsi_end_p (gsi))
> +	goto return_pred;
> it looks like this might cause -g vs. -g0 issues, so better use
> gsi_last_nondebug_bb here.

[Sanity check here, Jakub:]

I don't *think* this is necessary.  The reason for that check
is to avoid a null-pointer dereference in the immediately
following gsi_stmt.  At which point a debug stmt should not
be stmt_ends_bb_p and we also accept the predecessor block.

But in any case if we made the change here, we also have to
change gimple_find_edge_insert_loc.  The functions really do
have to match.


Which brings me to a point of irritation.  Why do cgraph edges
have to duplicate something as complex as the frequency?  Why
can't we get the edge frequency from the basic block?

My problem here is that when I create the call stmt I have all
of the data handy to create the cgraph edge.  What I do not
have is the location at which the call stmt will be inserted.
In the case of insertting on an edge, the block will be created
later by gsi_commit_edge_inserts.  So instead I have to guess
what gsi_commit_edge_inserts is going to do and guess what
frequency the chosen block will have.

My problem is that I have to duplicate code from gsi_commit_edge_inserts
one way or the other.  Either the duplication above, or I have to
split the edges myself ahead of time (possibly unnecessarily, since
I don't yet know that there is something that needs insertting).


> Which makes me wonder how we lower emultls accesses inside
> debug stmts?

Debug stmts track registers; TLS variables live in static memory.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]