llvm dev - May 2011 - [LLVMdev] Can I get the binary address of a for-loop statement?

On 4/26/11 10:32 PM, Jim Grosbach wrote:
> In general, this is not possible. Consider, for example, the fact that
various optimization passes may reorder the code, including such things as
hoisting computations outside of the loop, and enclosing loops, scheduling those
instructions before others that did not originate from source lines within the
loop, etc. That's not to mention things like loop unrolling.
Another thing that might work would be to insert inline assembly 
statements that define symbols before and after the loop.  The LLVM 
optimizations shouldn't move loop code around these inline assembly 
statements (if the statements are labeled as modifying memory in a 
volatile manner), but optimizations between the inline assembly 
statements should remain unfettered.

Granted, you might pessimize optimization a bit, but whether that's an 
issue depends upon your application.

-- John T.
> That said, especially at low optimization levels, you may be able to get at
least an approximation of what you're after from debug information. See
http://llvm.org/docs/SourceLevelDebugging.html for an overview.
>
> Regards,
> -Jim
>
> On Apr 26, 2011, at 7:57 PM, 陳韋任 wrote:
>
>> Hi, all
>>
>>   What I want to do is to locate the range of a for-loop statement in
>> a binary. For example, given a for-loop statement belows,
>>
>> for (stat1; stat2; stat3) {
>>   /* do something */
>> }
>>
>>   Is it possible to get information about the range (binary address)
>> of the above for-loop, say, 0x0100 - 0x0120.
>>
>>   One idea comes up in my mind is adding passes to retrieve such
>> information in LLVM, then use llvm-gcc to compile the code.
>>
>>   Any suggestion appreciated.
>>
>> Regards,
>> chenwj
>>
>> -- 
>> Wei-Ren Chen (陳韋任)
>> Computer Systems Lab, Institute of Information Science,
>> Academia Sinica, Taiwan (R.O.C.)
>> Tel:886-2-2788-3799 #1667
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> Another thing that might work would be to insert inline assembly
> statements that define symbols before and after the loop.  The LLVM
> optimizations shouldn't move loop code around these inline assembly
> statements (if the statements are labeled as modifying memory in a
> volatile manner), but optimizations between the inline assembly
> statements should remain unfettered.
By the way, is it possible to insert additional labels using the
inline assembly statements?
I understand this may degrade the optimization quality, but it could
be done at the last optimization stage.

Alexander Potapenko

On 5/12/11 5:14 AM, Alexander Potapenko wrote:
>> Another thing that might work would be to insert inline assembly
>> statements that define symbols before and after the loop.  The LLVM
>> optimizations shouldn't move loop code around these inline assembly
>> statements (if the statements are labeled as modifying memory in a
>> volatile manner), but optimizations between the inline assembly
>> statements should remain unfettered.
> By the way, is it possible to insert additional labels using the
> inline assembly statements?
> I understand this may degrade the optimization quality, but it could
> be done at the last optimization stage.
I think so but have never tried it.

-- John T.
> Alexander Potapenko