home.social

Search

536 results for “llvm”

  1. Join me at #LLVM / #Clang #Meetup #Darmstadt meetu.ps/e/Q1pwf/ZJC7X/i

    We’ll have Jan André Reuter talk about the Score-P plugin for LLVM.
    Then we’ll have pizza, drinks, and discussions as usual.

    May 27th at 7pm

    @llvmweekly @llvm

  2. My vision for the loop vectorizer in #LLVM has finally crystallized into a first patch! The line of work would have a major impact on optimization result as well as compile time! 🎉

    github.com/llvm/llvm-project/p

  3. My overall vision for what #LLVM VPlan should ideally be is becoming clearer. It's going to be huge design overhaul, and the work has to be done piece-wise with no unit of work causing regressions. The hard part is convincing all stakeholders to align on the vision, which I cannot explain in natural language sufficiently well.

  4. I need a recap for how to write plugins for #llvm
    What is you favourit blog post or book on this topic.
    Please share.

    Yes yes I am reading the docs also

    #development #compiler

  5. ”You cannot boot Windows without #llvm today.” - Clang and LLVM in modern gaming, panel at EuroLLVM.

  6. 🎉 Oh, joy! Another thrilling day in the life of a programmer chasing bugs in #LLVM #RISC-V while pretending to be Sherlock Holmes. 🔍 The article takes us on a wild ride through benchmarks and code tweaks, but spoiler alert: we still don't really care. 📉
    blog.kaving.me/blog/tracking-d #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated

  7. 🎉 Oh, joy! Another thrilling day in the life of a programmer chasing bugs in #LLVM #RISC-V while pretending to be Sherlock Holmes. 🔍 The article takes us on a wild ride through benchmarks and code tweaks, but spoiler alert: we still don't really care. 📉
    blog.kaving.me/blog/tracking-d #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated

  8. 🎉 Oh, joy! Another thrilling day in the life of a programmer chasing bugs in #LLVM #RISC-V while pretending to be Sherlock Holmes. 🔍 The article takes us on a wild ride through benchmarks and code tweaks, but spoiler alert: we still don't really care. 📉
    blog.kaving.me/blog/tracking-d #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated

  9. 🎉 Oh, joy! Another thrilling day in the life of a programmer chasing bugs in #LLVM #RISC-V while pretending to be Sherlock Holmes. 🔍 The article takes us on a wild ride through benchmarks and code tweaks, but spoiler alert: we still don't really care. 📉
    blog.kaving.me/blog/tracking-d #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated

  10. @resistor has been spelunking in LLVM history and found my first LLVM commit! from just over 18 years ago! Truly an indispensable contribution to the ecosystem!

    #llvm

  11. Как найти UB, которое никто не хочет замечать: разбираем clang-tidy изнутри

    Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре. Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке. В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно. Отправимся на поиски и поимку UB →

    habr.com/ru/companies/yadro/ar

    #llvm #clangtidy #ast #check #cpp #undefined_behavior #UB #compiler #sanitizers

  12. Wondering if it is possible to make #llvm / #clang produce assembly code that ensures a function has a single exit point that the flow always goes through whenever the function exits (excluding exceptions).

    Theoretically one could convert all ret into unconditional jmp to a single ret and this should be possible using a llvm pass. Unfortunately I cannot modify the Clang/llvm I need this for.

    So wondering if something like this is already there, maybe even as a per-function annotation. Anyone?

  13. KDAB engineer Shivam Kunwar contributed a fix to LLVM/Clang that enables debuggers to display constexpr array contents in optimized builds. Previously, inspecting static constexpr arrays under -O2 showed "no symbol in current context", now GDB and LLDB show the actual values. A small but meaningful improvement for anyone debugging optimized C++. #LLVM #Clang #DebugInfo #DWARF #CPlusPlus #OpenSource

    More details:
    github.com/llvm/llvm-project/p

  14. KDAB engineer Shivam Kunwar contributed a fix to LLVM/Clang that enables debuggers to display constexpr array contents in optimized builds. Previously, inspecting static constexpr arrays under -O2 showed "no symbol in current context", now GDB and LLDB show the actual values. A small but meaningful improvement for anyone debugging optimized C++. #LLVM #Clang #DebugInfo #DWARF #CPlusPlus #OpenSource

    More details:
    github.com/llvm/llvm-project/p

  15. KDAB engineer Shivam Kunwar contributed a fix to LLVM/Clang that enables debuggers to display constexpr array contents in optimized builds. Previously, inspecting static constexpr arrays under -O2 showed "no symbol in current context", now GDB and LLDB show the actual values. A small but meaningful improvement for anyone debugging optimized C++. #LLVM #Clang #DebugInfo #DWARF #CPlusPlus #OpenSource

    More details:
    github.com/llvm/llvm-project/p

  16. KDAB engineer Shivam Kunwar contributed a fix to LLVM/Clang that enables debuggers to display constexpr array contents in optimized builds. Previously, inspecting static constexpr arrays under -O2 showed "no symbol in current context", now GDB and LLDB show the actual values. A small but meaningful improvement for anyone debugging optimized C++.

    More details:
    github.com/llvm/llvm-project/p

  17. Flame: Системный язык программирования на C и LLVM с мета-исключениями и Memory Safety без Borrow Checker

    Пока индустрия движется в сторону усложнения компиляторов, я задался вопросом: можно ли создать инструмент, который дает безопасность Rust, гибкость C и при этом не весит сотни мегабайт? Так появился Flame — системный язык с компилятором в 226 КБ , который реализует управление памятью через статический анализ AST и предлагает альтернативный взгляд на обработку ошибок через патчинг дерева токенов.

    habr.com/ru/articles/1007758/

    #flame #c #c++ #c# #системное_программирование #компиляторы #компилятор #коддинг #llvm #llvm_ir

  18. Профилирование и PGO в LLVM

    Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.

    habr.com/ru/articles/1006620/

    #llvm #pgo #clang #компиляторы

  19. Oh, joy, clang-format 22 has compounded an existing bug where AllowShortBlocksOnASingleLine: Empty didn't work by applying the AllowShortBlocksOnASingleLine setting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn.

    #llvm #ClangFormat

  20. Oh, joy, clang-format 22 has compounded an existing bug where AllowShortBlocksOnASingleLine: Empty didn't work by applying the AllowShortBlocksOnASingleLine setting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn.

    #llvm #ClangFormat

  21. Oh, joy, clang-format 22 has compounded an existing bug where AllowShortBlocksOnASingleLine: Empty didn't work by applying the AllowShortBlocksOnASingleLine setting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn.

    #llvm #ClangFormat

  22. Oh, joy, clang-format 22 has compounded an existing bug where AllowShortBlocksOnASingleLine: Empty didn't work by applying the AllowShortBlocksOnASingleLine setting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn.

    #llvm #ClangFormat

  23. LLVM Bug: x86-64 inline assembly fails with "symbol is already defined" for local labels under optimization (-O1+)

    When compiling x86-64 inline assembly that contains explicitly named local labels (e.g., `.Lcoro_resume_task_ret_addr`), Clang throws a "symbol is already defined" error if optimizations (-O1, -O2, -O3) are enabled. The exact same code compiles successfully at -O0 in Clang, and works perfectly across all optimization levels in GCC.

    github.com/llvm/llvm-project/i

    #llvm #x86_64 #x86

  24. Interestingly, when building Pocl with the option to statically link against LLVM 18, the crash can be reproduced by simply running `clinfo -l` (which is the least-intrusive OpenCL-using command you can run, basiclaly) and the error is caused by the good old

    : CommandLine Error: Option 'internalize-public-api-file' registered more than once!
    LLVM ERROR: inconsistency in registered CommandLine options

    during the Pocl ICD device numeration.

    *sigh*

    #llvm #clang #pocl #rusticl #mesa

  25. Interestingly, the segfault seems to be from clang::DiagonsticOptions from llvm-21, so this is likely one of the neverending series of issues that arise when mixing #LLVM versions that has plagued #FLOSS #OpenCL ICDs since forever. I thought we had finally gotten rid of these issues, but apparently this is not the case: dynamic loading independent libraries that depend on different versions of LLVM *still* causes issues. Is it again some unversioned global? Another weird gimmick? Who knows!

  26. The LLVM project has been offering "office hours" for many years now, where experienced developers make themselves available for a chat with anyone on LLVM topics at regular times. I'm hosting an #LLVM #OfficeHours every 2 weeks. Next one is this Wednesday the 28th, at 9:30am CET, at meet.jit.si/KristofBeylsLLVMOf. Come join me to talk about anything #llvm. A list of everyone hosting office hours is at llvm.org/docs/GettingInvolved..