On Sat, Oct 17, 2009 at 12:44 AM, Justin Seyster <jrs...@gmail.com> wrote: > I'm currently porting a plug-in that used to target the 4.3.0-based > plug-in branch to the new top-of-tree plug-in system. I'm really > stymied by a bug whose source I just cannot track down! Usually that > means there is an error in my code, but the problem seems to involve > tree-ssa-dse.c and tree-ssa-alias.c, so I wanted to ask for a bit of > help from the list. > > The plug-in is relatively simple: it's designed to synthesize calls to > a hook function in specific places. I streamlined the plug-in to the > simplest case that still triggers the bug: the function call has just > one argument, which is a pointer to a string constant. > > The test program I'm instrumenting gets hook calls in two places. The > first one goes in without a problem (I can compile the program and > verify that the hook gets called with the correct string), but the > second (basically identical) call triggers an assertion failure during > the Dead Store Elimination (dse) pass. > > The problem occurs in dse_possible_dead_store_p() getting called for a > GIMPLE_ASSIGN that comes just before the inserted GIMPLE_CALL in the > same basic block. dse_possible_dead_store_p() pulls the gimple_vdef > out of this GIMPLE_ASSIGN (which is an SSA_NAME reference to .MEM) and > then iterates through its imm_uses list (with FOR_EACH_IMM_USE_STMT). > > The surpise to me is that my inserted GIMPLE_CALL hook is somehow in > that list! That results in dse_possible_dead_store_p() checking the > hook call with ref_maybe_used_by_call_p(), which goes through each > argument in the call (in this case just a pointer to a string > constant) to check if it aliases with another variable with > refs_may_alias_p_1(). > > The reference is an ADDR_EXPR, though, which it appears does not ever > belong in refs_may_alias_p_1(). I say that because of the assertion > statement at the because of refs_may_alias_p_1(): > > gcc_assert ((!ref1->ref > || SSA_VAR_P (ref1->ref) > || handled_component_p (ref1->ref) > || INDIRECT_REF_P (ref1->ref) > || TREE_CODE (ref1->ref) == TARGET_MEM_REF)... > > My ADDR_EXPR does not meet any of those conditions, so something has > gone wrong here! > > After figuring all that out, I'm stuck with a ton of questions: > > 1) Why is my inserted GIMPLE_CALL hook ending up in some SSA_NAME's > imm_uses list? The correctly working hook never gets inserted onto an > imm_uses list, so what could be making this one different? Is it > possible that I malformed the GIMPLE_CALL in some way that would cause > that?
Because your call has side-effects on global memory, this is how they are represented. If your calls do not have such side-effects you should mark them accordingly - as pure, const or simply no-vops. > 2) Why is the assertion at the beginning of may_alias_p_1() there? > Somebody is responsible for making sure that refs who don't pass this > check never end up in may_alias_p_1(), but who? Should > ref_maybe_used_by_call_p() actually be making this check before > calling may_alias_p_1(), or should I be forming GIMPLE_CALLs so that > all their arguments are suitable for may_alias_p_1()? I think the call you insert is not of valid gimple form - an address argument has to fulfill the is_gimple_min_invariant() predicate. Thus I suspect you have something like &ptr->field in there which needs a temporary. Richard. > Sorry for this enormous brain-dump e-mail! I'm still really new to > GCC, and I'd appreciate any guidance I can get here. Thanks. > --Justin >
