Regarding scope information for variable declaration.

Hi All,

I have question regarding lexical scope information.

If I have .c source with scope as below.

void func()
{
//-- some code here…
{ //parent scope
if() //high pass
{
int i;
for( i =0; i < FRAM_I; i++)
{
}
}
if() //low pass
{
int i;
for( i =0; i < FRAM_J; i++)
{
}
}
}
}

In this case, the ‘variable i’ is not initialized in any of the if scope, so it should belong to which scope?
Is it ok, if ‘scope information’ gives me that it belongs to the parent scope of ‘if-scope’?
Is it because the scope information is collected for machine instructions, and as there will be not machine corresponding to ‘int i;’, and thus no scope will be associated with it?

Regards,
Pankaj

I have the same demand. Have you resolved this problems? if so, would you
share me the solution?

Best Regards.

Eric

Hi Eric,

I was considering machine instructions to get scope information. And variable declaration does not correspond to machine instruction, hence the problem i.e. no scope associated with it. If ‘i’ is initialized in the ‘if-scope’ then we get ‘variable i’ mapped to correct scope as corresponding machine instruction is generated for this. This is not a problem as we can’t expect variable declaration in a machine instruction, I thought.

So instead of using machine instructions to collect scope information, (as used by LexicalScope pass), I had written code to collect scope information based on LLVM Instructions. I did this by iterating over ‘Function->BasicBlock’ instead of ‘MachineFunction->MachineBasicBlock’.
const Function *F1 = MF->getFunction();
for(Function::const_iterator BB = F1->begin(), E = F1->end();
BB != E; ++BB)
{
for(BasicBlock::const_iterator ii = BB->begin(), ie = BB->end();
ii != ie; ++ii)
{
const Instruction *I = ii; //I->dump();//debug
DebugLoc MIDB = I->getDebugLoc();
}
}

Though this is an overhead as scope information exists, but I need to collect specific information such as ‘start line, end line, start column, end column’ (End line information should be derived as is not obvious).

Collecting information this way allowed me to get correct scope information, and hence I was able to map the variable declaration to the scope. It worked for me this way.

Regards,
Pankaj

Hi Eric,

I was considering machine instructions to get scope information. And variable declaration does not correspond to machine instruction, hence the problem i.e. no scope associated with it.
If ‘i’ is initialized in the ‘if-scope’ then we get ‘variable i’ mapped to correct scope as corresponding machine instruction is generated for this.
This is not a problem as we can’t expect variable declaration in a machine instruction, I thought.

So instead of using machine instructions to collect scope information, (as used by LexicalScope pass),
I had written code to collect scope information based on LLVM Instructions.
I did this by iterating over ‘Function->BasicBlock’ instead of ‘MachineFunction->MachineBasicBlock’.
const Function *F1 = MF->getFunction();
for(Function::const_iterator BB = F1->begin(), E = F1->end();
BB != E; ++BB)
{
for(BasicBlock::const_iterator ii = BB->begin(), ie = BB->end();
ii != ie; ++ii)
{
const Instruction *I = ii; //I->dump();//debug
DebugLoc MIDB = I->getDebugLoc();
}
}

Though this is an overhead as scope information exists,
but I need to collect specific information such as ‘start line, end line, start column, end column’
(End line information should be derived as is not obvious).

Collecting information this way allowed me to get correct scope information,
and hence I was able to map the variable declaration to the scope. It worked for me this way.

Regards,
Pankaj

Thank your reply. Pankaj.

Actually, I have done it very similar to yours. But I think for my demand, it is better to implement in Front End. Maybe I will re-implement it later in clang.

Thank your reply. Pankaj.

Actually, I have done it very similar to yours. But I think for my demand,
it is better to implement in Front End. Maybe I will re-implement it later
in clang.

Depends what you're trying to do with this scope information... if
it's purely for optimization purposes then it should just be in LLVM,
with the exception of something like LLVM's lifetime intrinsics, used
as a hint from the frontend.