Search
586 results for “llvm”
-
Join me at #LLVM / #Clang #Meetup #Darmstadt https://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
-
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! 🎉
-
Low-Compilation-Cost Register Allocation in LLVM-Based Binary Translation
-
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.
-
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
-
”You cannot boot Windows without #llvm today.” - Clang and LLVM in modern gaming, panel at EuroLLVM.
-
🎉 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. 📉
https://blog.kaving.me/blog/tracking-down-a-25-regression-on-llvm-risc-v/ #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated -
🎉 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. 📉
https://blog.kaving.me/blog/tracking-down-a-25-regression-on-llvm-risc-v/ #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated -
🎉 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. 📉
https://blog.kaving.me/blog/tracking-down-a-25-regression-on-llvm-risc-v/ #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated -
🎉 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. 📉
https://blog.kaving.me/blog/tracking-down-a-25-regression-on-llvm-risc-v/ #programmerlife #bugchasing #SherlockHolmes #codebenchmarks #techhumor #HackerNews #ngated -
Tracking down a 25% Regression on LLVM RISC-V
https://blog.kaving.me/blog/tracking-down-a-25-regression-on-llvm-risc-v/
-
@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!
-
Как найти UB, которое никто не хочет замечать: разбираем clang-tidy изнутри
Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре. Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке. В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно. Отправимся на поиски и поимку UB →
https://habr.com/ru/companies/yadro/articles/1017930/
#llvm #clangtidy #ast #check #cpp #undefined_behavior #UB #compiler #sanitizers
-
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?
-
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:
https://github.com/llvm/llvm-project/pull/182442 -
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:
https://github.com/llvm/llvm-project/pull/182442 -
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:
https://github.com/llvm/llvm-project/pull/182442 -
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:
https://github.com/llvm/llvm-project/pull/182442 -
Flame: Системный язык программирования на C и LLVM с мета-исключениями и Memory Safety без Borrow Checker
Пока индустрия движется в сторону усложнения компиляторов, я задался вопросом: можно ли создать инструмент, который дает безопасность Rust, гибкость C и при этом не весит сотни мегабайт? Так появился Flame — системный язык с компилятором в 226 КБ , который реализует управление памятью через статический анализ AST и предлагает альтернативный взгляд на обработку ошибок через патчинг дерева токенов.
https://habr.com/ru/articles/1007758/
#flame #c #c++ #c# #системное_программирование #компиляторы #компилятор #коддинг #llvm #llvm_ir
-
Профилирование и PGO в LLVM
Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.
-
Oh, joy, clang-format 22 has compounded an existing bug where
AllowShortBlocksOnASingleLine: Emptydidn't work by applying theAllowShortBlocksOnASingleLinesetting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn. -
Oh, joy, clang-format 22 has compounded an existing bug where
AllowShortBlocksOnASingleLine: Emptydidn't work by applying theAllowShortBlocksOnASingleLinesetting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn. -
Oh, joy, clang-format 22 has compounded an existing bug where
AllowShortBlocksOnASingleLine: Emptydidn't work by applying theAllowShortBlocksOnASingleLinesetting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn. -
Oh, joy, clang-format 22 has compounded an existing bug where
AllowShortBlocksOnASingleLine: Emptydidn't work by applying theAllowShortBlocksOnASingleLinesetting to functions, meaning that there is no way for us to move to clang 22 without some formatting churn. -
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.
-
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 optionsduring the Pocl ICD device numeration.
*sigh*
-
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!
-
-
-
