Actions
Feature #341
closedBLAST must process must-aliases comming from aspectator
Start date:
08/05/2010
Due date:
% Done:
0%
Estimated time:
Published in build:
e2a8d1f
Description
Pavel Shved 2010-01-20 16:40:05 MSK
struct l_struct_2E_mutex *blast_must_tmp__3;
unsigned int blast_must_tmp__4;
struct l_struct_2E_mutex *blast_must_tmp__5;
...
blast_must_tmp__3 = *(&llvm_cbe_aaa);
blast_must_tmp__4 = *((&blast_must_tmp__3->field0));
blast_must_tmp__5 = *(&llvm_cbe_aaa);
blast_must_tmp__6 = (&blast_must_tmp__5->field1);
if ((blast_must_tmp__4 != 0u)) {
goto llvm_cbe_bb;
} else {
goto llvm_cbe_bb1;
}
llvm_cbe_bb:
*blast_must_tmp__6 = 10u;
goto llvm_cbe_bb2;
llvm_cbe_bb1:
*blast_must_tmp__6 = 20u;
goto llvm_cbe_bb2;
I identified the problem. The thing is that in current BLAST must-aliasing infrastructure expression "*blast_must_tmp__6" is a must-alias, because it is based on an identifier with special must-prefix. The thing is that in this case the "tag" expression is mere "blast_must_tmp__6", but in other cases it may be "*(mem_3->xxx)". The method to distinguish them is needed.
Updated by Evgeny Novikov over 13 years ago
- Status changed from New to Resolved
There is no more the given issue since we have moved aspectator from LLVM to GCC. Since we don't intend to support LLVM-based aspectator widely we shouldn't take care on this problem.
Updated by Pavel Shved over 13 years ago
- Tracker changed from Bug to Feature
- Status changed from Resolved to Rejected
This feature still may somehow arise; however, we do not plan to support aspectator, and BLAST's alias analysis needs a serious rework.
Actions