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 Tue, Jul 20, 2010 at 6:16 PM, Richard Henderson <> wrote:
> 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.
> <rant>
> 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?

Because we need the frequencies during WPA stage where we
do not have basic-blocks.

> 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.

Couldn't you do gsi_insert_on_edge_immediate?  Btw, edge
frequencies for calls that call to external functions are not used
for anything I think.

> 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).
> </rant>
>> Which makes me wonder how we lower emultls accesses inside
>> debug stmts?
> Debug stmts track registers; TLS variables live in static memory.

Oh, indeed.


> r~

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