Missing SSA Info

Question

I am having some problems with SSA.

 

I generate SssaInfo at the beginning of the plugin, perform my transformations, and then I perform SsaInfo->Delete(), recreate SsaInfo, and rerun Build.

 

The SSA information is regenerated fine for most of the program. However, it seems like VariableOperands that I created during my transformations do not have SSA information on them.

 

For example, I create a counter operand as follows:

 

Code Snippet

 

search_name = Phx::Name::New(functionUnit->Lifetime, "outerCounter0");

Phx::Symbols::LocalVariableSymbol ^new_counter_symbol =
 Phx::Symbols::LocalVariableSymbol::NewAuto
 (functionUnit->SymbolTable, 0, search_name,
  functionUnit->TypeTable->Int32Type);

Operand ^outerCounterOperand =
 VariableOperand::New
 (functionUnit, new_counter_symbol->Type, new_counter_symbol);

 

 

However, even after using the outerCounter Operand repeatedly, there doesn't appear to be have been any SSA information generated for it.

 

==== BasicBlock 16 Predecessor(5) Successor(20) previous 15 next 17
$L20: (references=1)                                                        #65
   outerCounter0     = ASSIGN 0                                             #65
                       GOTO $L24                                            #65
==== BasicBlock 17 Predecessor(36,35,34,7) Successor(28) previous 16 next 18
$L21: (references=4)                                                        #65
   stCoalesceCounter0 = ASSIGN 0                                            #65
   tv354-<5>         = MULTIPLY outerCounter0, 32(0x00000020)               #65
   t355              = CONVERT &?threadIdx@@3Udim3@@A                       #65
   thix              = ASSIGN t355                                          #65
   stModedCounter0   = ADD tv354-<5>, thix                                  #65
                       GOTO $L32                                            #65
==== BasicBlock 18 Predecessor(28) Successor(20) previous 17 next 19
$L22: (references=1)                                                        #65
   outerCounter0     = ADD outerCounter0, 1                                 #65
                       GOTO $L24                                            #65

If anyone can shed some light on this, I would really appreciate it.

 

Thank you,

Sain

Answer 1

I would guess that for some reason we think your new variables are aliased, and you are building SSA for unaliased only. Are you taking the address of &outerCounter0 anywhere?

 

To confirm this, can you try building SSA for aliased (that is, set your ssa build attribute to Aliased) -- and see if this puts your new locals into SSA form?

 

Answer 2

No, I'm not taking the address of outerCounter0.

 

By building SSA for aliased, do you mean like the following?

 

Code Snippet

      functionUnit->SsaInfo = Phx::SSA::Info::New(functionUnit->Lifetime, functionUnit,
       Phx::SSA::Attribute::Aliased,
       Phx::SSA::BuildOption::Default);

 

 

 

I was originally using NotAliasedScalars. Unfortunately, switching to Aliased did not put he new locals into SSA form.

 

Thank you,

Sain

Answer 3

Yes, that's what I meant. But evidently the problem is elsewhere.

 

When are you running your plugin (after which phase)? If I modify the Loop Instrumentation sample to build SSA after it finishes instrumentation, the newly introduced loop counters are put into SSA form.

 

Answer 4

Hello Andy,

 

I'm sorry, but I made a mistake. Changing the SSA build to Aliased does produce SSA info for all of my new local variables. However, it also introduces CHI instructions and {Virtual} Operands.

 

I was using SSA to trace back along the DefinitionOperand to generate the expression for certain instructions. My current expression generation algorithm now gets trapped by the {Virtual} Operands and the CHI instructions, since parts of the expression do touch memory access.

 

Could you perhaps explain in more detail what these constructs are for and if there is some way I can get around this problem?

 

Thank you,

Sain

Answer 5

The CHI's and virtual operands are there to record alias interference. Aliased locations are partitioned into equivalence classes, and each class is given a virtual variable to represent the class as a whole. Each operation that potentially updates a class member must be followed by a CHI that merges this update back into the whole. In some cases (eg calls that can throw) the merge information needs to be recorded on the updating instruction directly.

 

If you don't care about aliasing then you can just walk back through a chain of CHIs to find the individual updates to the locations. Or you can be a bit more careful and follow the chain back only if the CHIs you skip through modify non-overlapping parts of the partition (SSA building already tries to do this, but it gives up after some number of CHIs).

 

More specifically, suppose y is an aliased location, and you're at a use of y, and the definition of y is a virtual varible at a CHI. Look at the first source operand of the CHI -- this represents the specific part of the update. If that source operand is y then walk back from that to the definition to find the "real" defintion for y. If the source operand is something that partially overlaps with y then you have potential aliasing and need to decide what the appropriate action is for whatever it is you are trying to do.

 

Answer 6

Hello Andy,

 

I have not looked into getting around CHIs yet, but I've found an alternative to my problem.

 

I had used AllMemoryTag for some of the Address Operands that I was inserting. I switched to NotAliasedMemoryTag and SSA builds fine using NotAliasedScalars. This should be fine for me since I'm basically loading from memory for the most part and I understand that the few writes I do are safe.

 

Hopefully this alternative will be sufficient for my work.

 

Thanks for all of your help.

 

Sain