Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
On 8/14/19 3:52 PM, Ismail Bennani via lldb-dev wrote: > Hi everyone, > > I’m Ismail, a compiler engineer intern at Apple. As a part of my internship, > I'm adding Fast Conditional Breakpoints to LLDB, using code patching. > > ... > > Since all the registers are already mapped to a structure, I should > be able to support more __DWARF Operations__ in the future. > > After collecting some metrics on the __Clang__ binary, built at __-O0__, > the debug info shows that __99%__ of the most used DWARF Operations are : > > |DWARF Operation| Occurrences | > |---|---| > |DW\_OP_fbreg | 2 114 612 | > |DW\_OP_reg | 820 548 | > |DW\_OP_constu | 267 450 | > |DW\_OP_addr|17 370 | > > | __Top 4__ | __3 219 980 Occurrences__ | > |---|---| > | __Total__ | __3 236 859 Occurrences__ | > > Those 4 operations are the one that I'll support for now. > To support more complex expressions, we would need to JIT-compile > a DWARF expression interpreter. First, this all sounds really useful. Out of curiosity, how do these statistics change if you compile Clang with -O1? Many of my users need to debug slightly-optimized code. -Hal -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
On 8/16/19 10:27 AM, Adrian Prantl wrote: > >> On Aug 15, 2019, at 2:03 PM, Ismail Bennani via lldb-dev >> wrote: >> >> I built Clang (and LLVM) in Release Mode with Debug Info (-O2), >> and got these results: >> >> | Dwarf Occurences |Occurences | >> |--|-| >> | DW\_OP\_deref|1,570| >> | DW\_OP\_const|3,791| >> | DW\_OP\_addr |9,528| >> | DW\_OP\_lit |62,826 | >> | DW\_OP\_fbreg|205,382 | >> | DW\_OP\_piece|242,888 | >> | DW\_OP\_stack\_value |992,261 | >> | DW\_OP\_breg |1,006,070| >> | DW\_OP\_reg |5,175,831| >> | **Total**| **7,700,147** | >> >> >> I could technically implement the logic to support DW_OP_reg, DW_OP_breg >> and DW_OP_stack_value fairly easily (which still represents 90% of all ops). >> >> However, DW_OP_piece is a more complex operation since it combines >> several other operations, and would require more work. >> >> This would also imply that there will 2 DWARF Expression Interpreter in >> LLDB, hence twice as much code to maintain … I’ll try to see if I can >> use the existing interpreter for this feature. > I strongly agree that unless the code can be shared, the JIT-ed DWARF > expression interpreter should be kept as simple as possible and aim to > support the lion's share of DWARF expressions encountered in a typical > program, but making it support 100% is a lot of effort and maintenance burden > with very diminishing returns. +1 (and, thanks for the data! I think it would be useful to support the things that we can easily support, but the more complicated things should be weighed carefully against the maintenance costs) -Hal > > -- adrian > >> Ismail >> >>> On Aug 14, 2019, at 3:42 PM, Finkel, Hal J. wrote: >>> >>> >>> On 8/14/19 3:52 PM, Ismail Bennani via lldb-dev wrote: Hi everyone, I’m Ismail, a compiler engineer intern at Apple. As a part of my internship, I'm adding Fast Conditional Breakpoints to LLDB, using code patching. ... Since all the registers are already mapped to a structure, I should be able to support more __DWARF Operations__ in the future. After collecting some metrics on the __Clang__ binary, built at __-O0__, the debug info shows that __99%__ of the most used DWARF Operations are : |DWARF Operation| Occurrences | |---|---| |DW\_OP_fbreg | 2 114 612 | |DW\_OP_reg | 820 548 | |DW\_OP_constu | 267 450 | |DW\_OP_addr|17 370 | | __Top 4__ | __3 219 980 Occurrences__ | |---|---| | __Total__ | __3 236 859 Occurrences__ | Those 4 operations are the one that I'll support for now. To support more complex expressions, we would need to JIT-compile a DWARF expression interpreter. >>> >>> First, this all sounds really useful. >>> >>> Out of curiosity, how do these statistics change if you compile Clang >>> with -O1? Many of my users need to debug slightly-optimized code. >>> >>> -Hal >>> >>> >>> -- >>> Hal Finkel >>> Lead, Compiler Technology and Programming Languages >>> Leadership Computing Facility >>> Argonne National Laboratory >>> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [Openmp-dev] RFC: End-to-end testing
On 10/17/19 10:00 AM, David Greene via cfe-dev wrote: > Mehdi AMINI via llvm-dev writes: > >> The main thing I see that will justify push-back on such test is the >> maintenance: you need to convince everyone that every component in LLVM >> must also maintain (update, fix, etc.) the tests that are in other >> components (clang, flang, other future subproject, etc.). Changing the >> vectorizer in the middle-end may require now to understand the kind of >> update a test written in Fortran (or Haskell?) is checking with some >> Hexagon assembly. This is a non-trivial burden when you compute the full >> matrix of possible frontend and backends. That's true, but at some point we really do just need to work together to make changes. If some necessary group of people become unresponsive, then we'll need to deal with that, but just not knowing whether the compiler works as intended seems worse. > That's true. But don't we want to make sure the complete compiler works > as expected? And don't we want to be alerted as soon as possible if > something breaks? To my knowledge we have very few end-to-end tests of > the type I've been thinking about. That worries me. I agree. We really should have more end-to-end testing for cases where we have end-to-end contracts. If we provide a pragma to ask for vectorization, or loop unrolling, or whatever, then we should test "end to end" for whatever that means from the beginning of the contract (i.e., the place where the request is asserted) to the end (i.e., the place where to can confirm that the user will observe the intended behavior) - this might mean checking assembly or it might mean checking end-stage IR, etc. There are other cases where, even if there's no pragma, we know what the optimal output is and we can test for it. We've had plenty of cases where changes to the pass pipeline, instcombine, etc. have caused otherwise reasonably-well-covered components to stop behaving as expected in the context of the complete pipeline. Vectorization is a good example of this, but is not the only such example. As I recall, other loop optimizations (unrolling, idiom recognition, etc.) have also had these problems over time > >> Even if you write very small tests for checking vectorization, what is >> next? What about unrolling, inlining, loop-fusion, etc. ? Why would we stop >> the end-to-end FileCheck testing to vectorization? > I actually think vectorization is probably lower on the concern list for > end-to-end testing than more focused things like FMA generation, > prefetching and so on. In my experience, these are about equal. Vectorization being later means that fewer things can mess things up afterwards (although there still is all of codegen), but more things can mess things up beforehand. -Hal > This is because there isn't a lot after the > vectorization pass that can be mess up vectorization. Once something is > vectorized, it is likely to stay vectorized. On the other hand, I have > for example frequently seen prefetches dropped or poorly scheduled by > code long after the prefetch got inserted into the IR. > >> So the monorepo vs the test-suite seems like a false dichotomy: if such >> tests don't make it in the monorepo it will be (I believe) because folks >> won't want to maintain them. Putting them "elsewhere" is fine but it does >> not solve the question of the maintenance of the tests. > Agree 100%. > >-David > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
