[llvm-dev] How to recover function parameter Value* when -O2 active
Johannes Doerfert via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 23 16:37:07 PST 2021
On 2/23/21 6:33 PM, K Jelesnianski wrote:
> Ah makes sense completely, I forgot about it being pass by value. Thanks
> again for clearing this up.
>
> Also unrelated but: I just discovered LLVM has its own discord and I posted
> my question there first, is it popular? Or is mailing list still more
> responsive?
I'd say that depends (on what and who you ask). You reach different
people through the different channels, for better or worse.
~ Johannes
>
> On Tue, Feb 23, 2021 at 7:18 PM Johannes Doerfert <
> johannesdoerfert at gmail.com> wrote:
>
>> On 2/23/21 6:08 PM, K Jelesnianski wrote:
>>> Thank you so much for your reply!
>>>
>>> I want my pass to run as late as possible to not be messed up by any of
>> the
>>> regular internal optimizations. I need a reference of i32 %b (regularly
>> we
>>> see this in IR as i32* %b) so if I understand you I think I need an
>>> indirection.
>>> In that case is it safe to just create an AllocaInst ? Does adding the
>>> AllocaInst effect the way the data flows between functions?
>>>
>>> The reason I am saying this is: Following my above example code,
>> assuming I
>>> am interested in the local variable "m" declared and set in main() (so a
>>> memory slot dedicated for "m" is created in the stack, right?), "m" is
>>> passed to foo(m), nothing is altered, "m" is further passed to bar().
>>> If I created the AllocaInst in bar and assign %b to it, will I be
>> creating
>>> a new stack memory slot for bar's Argument "b" and will then I be passing
>>> in the memory address of "b" (context of bar()) and not "m" (context of
>>> main()).
>>>
>>> I want to, if possible, pass the stack address of "m" (from the context
>> of
>>> main) to my profiling function call that is currently in the context of
>>> bar().
>> Your code *does not* pass the address of `m` in `main` to `foo`.
>> It passes `m` by value to `foo`, thus the argument `b`is a copy
>> of `m` if you want. You cannot recover the address of `m` in `foo`
>> by any legal means. In fact, the optimizer will realize there is
>> no need for stack allocations and put both `m` and `b` into (virtual)
>> registers instead. If you want to trace a stack allocation, trace
>> it early. If you "wait" and it is remove because it was not observed/
>> needed, it's gone for good.
>>
>> For your code, change it to:
>>
>> void foo(int *bptr) { int b = *bptr; ... }
>> void main(...) {
>> ...
>> *m = ...
>> ...
>> foo(&m);
>> }
>>
>> and then you can profile the `i32* %bptr` argument of foo which is
>> the "stack" address of `m` in `main`.
>>
>> ~ Johannes
>>
>>
>>
>>> On Tue, Feb 23, 2021 at 6:19 PM Johannes Doerfert <
>>> johannesdoerfert at gmail.com> wrote:
>>>
>>>> If you want to access the `llvm::AllocaInst` generated by Clang for
>>>> the argument you should run your pass early in the pipeline. If you
>>>> just want to see the value passed to `bar`, take the `llvm::Argument`
>>>> and pass it to your profiling function. If you need indirection for
>>>> some reason, create a new `llvm::AllocaInst`, store the `llvm::Argument`
>>>> you are interested in in it, and pass the `llvm::AllocaInst` to your
>>>> function.
>>>>
>>>> I hope this helps.
>>>>
>>>> ~ Johannes
>>>>
>>>>
>>>> On 2/23/21 3:19 PM, K Jelesnianski via llvm-dev wrote:
>>>>> Dear LLVM mailing list,
>>>>>
>>>>> I am currently having difficulty with figuring out how to get a
>> function
>>>>> parameter Value* when I am compiling with -O2. It seems -O2 performs an
>>>>> optimization that optimizes out the local variable formed for the
>>>> function
>>>>> parameter.
>>>>> I have a pass where I am inserting new function calls, and need to pass
>>>> the
>>>>> function parameters variable address. With -O0 this issue does not come
>>>> up
>>>>> as each function parameter when using -O0 gets its own AllocaInst and I
>>>> can
>>>>> leverage that Value* to pass to my new function call. I have tried to
>>>>> leverage llvm.dbg information but it seems LLVM is not inserting
>>>>> llvm.dbg.addr for me to use.
>>>>>
>>>>> Below is the code example I am working with:
>>>>> /* example.c */
>>>>> int fd_in;
>>>>> char* ut_addr;
>>>>>
>>>>> __attribute__((noinline)) void bar (int b){
>>>>> my_pass_function( &b ); // NEW (what I want to be done by my
>>>> pass)
>>>>> ut_addr = (char*) mmap( 0, b, my_prot, MAP_PRIVATE, fd_in, 0);
>>>>> }
>>>>>
>>>>> __attribute__((noinline)) void foo (int f){
>>>>> bar( f );
>>>>> }
>>>>>
>>>>> int main(int argc, char** argv){
>>>>> int m;
>>>>> struct stat statbuf;
>>>>> char *input;
>>>>>
>>>>> if( (fd_in = open ( input, O_RDONLY)) < 0){ /* open
>> the
>>>>> input file */
>>>>> return 0;
>>>>> }
>>>>> if( fstat( fd_in , &statbuf ) < 0 ){ /* find size of
>>>> input
>>>>> file */
>>>>> return 0;
>>>>> }
>>>>>
>>>>> m = statbuf.st_size;
>>>>> foo( m );
>>>>> return 0;
>>>>> }
>>>>> -----------------------------------------------------------------
>>>>> The original IR I get for bar() is below, as you can see the function
>>>>> parameter is the "raw" value "i32 %b" passed into the function and not
>> a
>>>>> variable that I can leverage, get its Value* . Hence when I run my
>> newly
>>>>> instrumented code, I get a segmentation fault.
>>>>>
>>>>> define void @bar(i32 %b) local_unnamed_addr #0 !dbg !35 {
>>>>> entry:
>>>>> call void @llvm.dbg.value(metadata i32 %b, metadata !39, metadata
>>>>> !DIExpression()), !dbg !44
>>>>> call void @llvm.dbg.value(metadata i64 1000, metadata !40, metadata
>>>>> !DIExpression()), !dbg !44
>>>>> call void @llvm.dbg.value(metadata i32 1, metadata !43, metadata
>>>>> !DIExpression()), !dbg !44
>>>>> %conv = sext i32 %b to i64, !dbg !45
>>>>> %0 = load i32, i32* @fd_in, align 4, !dbg !46, !tbaa !47
>>>>> %call = tail call i8* @mmap(i8* null, i64 %conv, i32 1, i32 2, i32
>> %0,
>>>>> i64 0) #7, !dbg !51
>>>>> store i8* %call, i8** @ut_addr, align 8, !dbg !52, !tbaa !53
>>>>> ret void, !dbg !55
>>>>> }
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list