@dexonsmith Thank you for your reply. Are you considering the case where -print-after-all is used along with -print-* pass? If so, shouldn't we have -print-module explicitly in the test case?
Wed, Jun 19
Tue, Jun 18
Hello, can you please explain a bit more about this change? What kind of redundant outputs avoided by this? Thanks!
Wed, Jun 5
@Hahnfeld Got it. Then it seems that there's not much we can do here :(
Tue, Jun 4
@Hahnfeld I'm not an OpenMP expert and don't have much strong argument here, but IMHO it might be confusing to have LLVM_ENABLE_FFI and LIBOMPTARGET_ENABLE_FFI have different default value from user's perspective. I wonder if we can set it off by default and explicitly turn it on for builds with test?
@grokos Thanks for the suggestion. What about this?
Mon, Jun 3
Addressed comments from @Hahnfeld. Thanks!
May 15 2019
Use isReachableFromEntry. Thank you for the suggestion!
Thank you for your comments @efriedma! I addressed your comments and added a test case. The test segfaults clang without proposed change.
May 14 2019
Friendly ping again. This is a fix for a compiler crash.
May 3 2019
Friendly ping. Thanks!
Apr 30 2019
Friendly ping for comments. Thanks!
Apr 29 2019
Apr 25 2019
Apr 22 2019
Hello @rsmith, @wenlei and I took another look at this, and we couldn't find any use of AnonymousTagLocations outside of debug info. If that's actually the case, wouldn't it make sense to have DebugColumnInfo to control the field even if AnonymousTagLocations the part of generic printing policy?
Apr 3 2019
Apr 2 2019
@wmi Thank you for the concrete example! I think what we need for your example is context-sensitive profiling and function specialization, not inlining. Admittedly we don't have an infrastructure in LLVM to support context-sensitive profiling for non-inlined case and we don't perform context sensitive function specialization...
@wmi Thank you for the detailed explanation!
@wmi Thanks for taking a look! Performance numbers were neutral from our side.
Apr 1 2019
Check for the new pass manager added. Thanks @wmi for the comment!
@wmi Thanks for the reply! I can totally understand that entry count is not as precise as total count, but still don't think current implementation is the right way to address the issue. As I mentioned in the summary it compares two different things (instruction level counter vs function level counter), opens up a possibility for optimizing against wrong function (e.g. long and cold function), and makes it hard to find the root cause of the performance issue.
Mar 28 2019
Remove unnecessary metadata.
Mar 26 2019
Feb 8 2019
Feb 7 2019
Addressing comments from @Hahnfeld. Thanks!
Feb 6 2019
Feb 4 2019
Jan 9 2019
Can you please provide a bit more context about when the client might want this function?
Nov 5 2018
Comments for the test updated. Thanks for the comment!
Friendly ping. Thanks!
Nov 4 2018
Oct 30 2018
@rsmith I see. Thank you for the clarification!
I think the context is Derived here. My understanding of http://wg21.link/p0968r0#2227 (in this patch's context) is that when Derived is aggregate initialized, the destructor for each element of Base is potentially invoked as well.
Oct 29 2018
Oct 25 2018
@dblaikie I see. The problem we're experiencing is that with Clang's naming scheme we end up having different function name between the original source and the preprocessed source (as macro expansion changes the column number). This doesn't work well for me if I want to use distcc on top of our caching system, as the caching scheme expects the output to be same as far as the original source has not been changed (regardless of it's compiled directly or first preprocessed then compiled), but the distcc preprocesses the source locally then sends it to the remote build machine (and we do not turn distcc on for all workflow). I wonder if you have any suggestion to resolve this issue? Thanks!
Oct 22 2018
@aprantl It is a debug info. If you compile test/CodeGenCXX/debug-info-anonymous.cpp file with clang -g2 -emit-llvm -S , you will find debug metadata something like distinct !DISubprogram(name: "foo<X::(anonymous enum at /home/twoh/llvms/llvm/tools/clang/test/CodeGenCXX/debug-info-anonymous.cpp:9:3)>", linkageName: "_Z3fooIN1XUt_EEiT_" ..., which will eventually be included in .debug_info section.
Oct 19 2018
Remove conflict line.
@joerg Sorry but I'm not sure if I understand your question. This doesn't pretend to honor source code order, but makes linker to place "hot" functions under .text.hot section (There's no guarantee of ordering between functions inside .hot.text section) while "cold" functions under .text.unlikely section. This is purely for performance.
Oct 18 2018
Rebase. Tests are provided in the clang counterpart (D34796).
Rebase. Sorry I somehow missed the recent comments. I addresses @davidxl's comment on documentation. Thanks!
Sep 19 2018
Sep 7 2018
Addressing comments from @echristo. Reverted option name change, and added a test case. Sorry I haven't work on this code for a while so it took time to invent a test case.
Sep 5 2018
Hello, I observed a case where atomic builtin generates libcall when the corresponding sync builtin generates an atomic instruction (https://bugs.llvm.org/show_bug.cgi?id=38846). It seems that the alignment checking for __atomic builtins (line 759 of this patch) results the difference, and wonder if the check is actually necessary. Could anyone please shed some light on understanding this? Thanks!
Aug 16 2018
Hello, I wonder if we need to keep linkonce_odr symbols live here as well. I observe a case that a vtable for template class initiated has linkonce_odr linkage and marked dead here, which results compiler crash at WholeProgramDevirt because the global variable for vtable doesn't have initializer (https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/IPO/WholeProgramDevirt.cpp#L676 assumes that GV has the initializer). Thanks!
Jul 16 2018
Addressing comments from @Hahnfeld. Thanks!
Apr 25 2018
Addressing comment from @mssimpso. Thanks!
Apr 24 2018
Hello @jlpeyton @tlwilmar, is there a chance that this breaks runtime/test/ompt/misc/api_calls_from_other_thread.cpp test? ompt_get_num_places() is expected to return 0 from the test but with this patch it returns 1, and I think it is because kmp_affinity_num_masks is set to 1 from kmp_create_affinity_none_places().
Apr 4 2018
Apr 3 2018
Apr 2 2018
Thanks @fhahn for the comments! I added comments about why we don't perform splitting for the callsites inside the landing pad. Please let me know if you think it is too verbose.
Addressing @junbuml's comments. Thanks!
Mar 31 2018
Mar 12 2018
Update test to check f2.llvm.0 as well.
@tejohnson Thanks for the clarification. Regarding hotness, I'm not sure if providing "some" hotness is better than leaving it as unknown if profile data is not provided (If profile data is given, as you said, VP metadata will be attached to the callsite). I'm afraid that synthesized hotness may confuse optimizers, but please let me know if you have different idea.
@tejohnson I think your right. What I meant was that when the metadata is imported to bar.o, it references f1 and f2 by their promoted names, which makes the declarations with the promoted names to be added. Did I get it right, or still miss something?
Dec 6 2017
Dec 5 2017
@jkorous-apple Got it. I agree that it would be better to move the comments to the header. Will land it soon. Thanks!
Dec 4 2017
Thanks @jkorous-apple for the comment. I think your suggestion is a more
precise description for the implementation, and adjusted the comments
Nov 29 2017
@jkorous-apple Thanks for the comments! Yeah, I was thinking of O(lenght_of_string) approach, but considering the complicatedness of the implementation (I guess the real implementation would be a bit more complex than your pseudo implementation to handle quote and '\n\r' '\r\n' cases) I decided to stay with O(length_of_string * number_of_endlines_in_string) but optimizing the number of move operations.
Nov 27 2017
Thanks @jkorous-apple for your comments. I modified the type for the variables and replaced unnecessary inserts and erases with updates.
Nov 20 2017
Addressing @vsapsai's comments. Thank you for the suggestion! Added test case actually finds an off-by-one error in the original patch. I improved the comments as well.
Nov 1 2017
Oct 25 2017
Oct 24 2017
Sep 29 2017