Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profiling file not generated #62

Open
flyree opened this issue May 21, 2015 · 3 comments
Open

Profiling file not generated #62

flyree opened this issue May 21, 2015 · 3 comments
Assignees

Comments

@flyree
Copy link
Collaborator

flyree commented May 21, 2015

I found a case when I was running llfi. This is the generated profiling IR:

%178 = landingpad { i8_, i32 } personality i8_ bitcast (i32 (...)* @gxx_personality_v0 to i8)
catch i8
null, !llfi_index !15416
call void @doProfiling(i32 59)
%179 = extractvalue { i8_, i32 } %178, 0, !llfi_index !15417
call void @doProfiling(i32 57)
call void @_clang_call_terminate(i8 %179) #11, !llfi_index !15418
call void @endProfiling()
unreachable, !llfi_index !15419

I am not sure this endProfiling function would be called. This has something to do with the exception handling in c++. I think endProfiling should be added before that terminate call.

@chipbuster
Copy link
Contributor

I've been getting a similar issue, though not entirely identical (the symptom is the same as the title of this issue, so I'll leave it here). In my case, main() is not having an endProfiling call placed before the return (following snippet is from main() in IR):

; <label>:157                                  ; preds = %151, %147, %144
  ret i32 0                                    ; corresponds to `return 0` at the end of main()

; <label>:158                                  ; preds = %113
  %159 = load i8** %4
  %160 = load i32* %5
  %161 = insertvalue { i8*, i32 } undef, i8* %159, 0
  %162 = insertvalue { i8*, i32 } %161, i32 %160, 1
  resume { i8*, i32 } %162
}

Curiously, when the code is compiled under -O3 or -O2, the correct endProfiling() call is inserted.

The code is the single-threaded LULESH benchmark.

@karfair
Copy link
Contributor

karfair commented Jun 26, 2015

@flyree Could you point me to the file you were using so that I can reproduce this bug? Thanks.

@flyree
Copy link
Collaborator Author

flyree commented Jun 26, 2015

Hi Phil,

I have found that it might be because that LLFI cannot deal with exception handling in C++ well. The program I am using is complex, but I guess you can find a c++ file with exception blocks (try/catch) and see how it goes.

Bo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants