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.

Sign up for GitHub

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

Jump to bottom

We need more examples code and comments. #56

Open
lanistor opened this issue Dec 10, 2019 · 6 comments
Open

We need more examples code and comments. #56

lanistor opened this issue Dec 10, 2019 · 6 comments
Labels
documentation question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!

Comments

@lanistor
Copy link

lanistor commented Dec 10, 2019 •
edited
Loading

When started to learn LLVM, i found the greatest resistance preventing me from moving forward, is the lacking of example code and code comments. The current code and comments only provide very little help, even a simple API will cost nearly half a day to found how to use it, and it always be resolved from google and stackoverflow, not from source code, not from official website.
So have you planed to provide more code comments and example code?
@lanistor lanistor changed the title We need more examples code. We need more examples code and comments. Dec 10, 2019
@dcci
Copy link
Member

dcci commented Dec 10, 2019

@vifird Do you have any specific example in mind?

@jyknight jyknight added documentation question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead! labels Dec 10, 2019
@lanistor
Copy link
Author

lanistor commented Dec 11, 2019 •
edited
Loading

Here are my cases:

  1. About getelementptr
    I know how to write getelementptr instruction by hand, but there seems no example to show how to generate this instruction with struct type, it cost me nearly a whole day to find the IRBuilder::CreateInBoundsGEP and the usage.
  2. About link c++ function
    All i found about linking c++ function, is addGlobalMapping from stackoverflow, but i cannot use it in version 10, thanks for this answer, i got LLJIT::defineAbsolute, but still blocked by using it.

More questions will appear, i will supplement then.

While, when i learn flutter frame, i can nearly get all i want from source code and code comments, that‘s really convenient and high-authority.

@bwendling
Copy link
Collaborator

This doc should give you a very good understanding of the basic layout and common data structures used by LLVM.

http://llvm.org/docs/ProgrammersManual.html

@lanistor
Copy link
Author

lanistor commented Dec 12, 2019 •
edited
Loading

@gwelymernans Had readed it already, helpless. The document tells you how to design you project, but doesn't tell you how to write your code with it.

@joker-eph
Copy link
Collaborator

In general, I think the Kaleidoscope tutorial is a good starting point to have a good tour of LLVM, but it isn't intended to be exhaustive in terms of visiting all the possible APIs though.

@lanistor
Copy link
Author

Yeah, example code may be the fast way for learning and using the huge number of APIs.

madscientist159 referenced this issue in madscientist159/llvm-project Jan 13, 2020
@ronlieb
Return success for submit/retrieve when host only (ROCm#56)
71fa352 
* Return success for submit/retrieve when host only

* typo
stelleg referenced this issue in lanl/kitsune Feb 21, 2020
@neboat
[BitcodeReader] Fixing bug that caused BitcodeReader to fail to proce…
22fcbbe 
…ss Tapir sync instructions correctly. This change addresses issue #56.
@russellw russellw mentioned this issue Jan 8, 2022
Closed
@zhouzhouyi-hub zhouzhouyi-hub mentioned this issue Feb 11, 2022
Open
@ajrh1 ajrh1 mentioned this issue Feb 18, 2022
Closed
@cho-regin cho-regin mentioned this issue Feb 22, 2022
Closed
@siggi-alpheus siggi-alpheus mentioned this issue Apr 5, 2022
Closed
@Wenmj201582 Wenmj201582 mentioned this issue Apr 22, 2022
Closed
@doocman doocman mentioned this issue Jun 5, 2022
Open
@dilyanpalauzov dilyanpalauzov mentioned this issue Oct 3, 2022
Open
@TatyanaDoubts TatyanaDoubts mentioned this issue Nov 4, 2022
Closed
jamesmth pushed a commit to jamesmth/llvm-project that referenced this issue Dec 5, 2022
@tlively @nikic
Update WebAssembly SIMD opcodes (llvm#56)
3f51097 
* [WebAssembly] Enable recently implemented SIMD operations

Summary:
Moves a batch of instructions from unimplemented-simd128 to simd128
because they have recently become available in V8.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D73926

* [WebAssembly] Simplify extract_vector lowering

Summary:
Removes patterns that were not doing useful work, changes the
default extract instructions to be the unsigned versions now that
they are enabled by default, fixes PR44988, and adds tests for
sext_inreg lowering.

Reviewers: aheejin

Reviewed By: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75005

* [WebAssembly] Renumber SIMD opcodes

Summary:
As described in WebAssembly/simd#209. This is
the final reorganization of the SIMD opcode space before
standardization. It has been landed in concert with corresponding
changes in other projects in the WebAssembly SIMD ecosystem.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79224
augusto2112 pushed a commit to augusto2112/llvm-project that referenced this issue Jan 23, 2023
@adrian-prantl
Work around an infinite recursion with deadlock that only exists on
ba81700 
the swift branch.

The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb.

One thing it does is resolve any unresolved global symbols in the JIT
module. This global search can cause the JIT module to recursively be
asked for its symtab.

This patch works around the problem by removing the JIT module from
the list of modules being searched while in PopulateSymtab. That isn't
done in the most elegant fashion, as it does so by changing the state
of the IRExecutionUnit object.

(lldb) bt
* thread llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame llvm#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame llvm#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame llvm#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame llvm#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt]
    frame llvm#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt]
    frame llvm#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt]
    frame llvm#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt]
    frame llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame llvm#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt]
    frame llvm#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt]
    frame llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame llvm#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt]
    frame llvm#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt]
    frame llvm#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt]
    frame llvm#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt]
    frame llvm#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt]
    frame llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame llvm#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame llvm#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame llvm#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame llvm#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame llvm#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt]
    frame llvm#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt]
    frame llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame llvm#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt]
    frame llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame llvm#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt]
    frame llvm#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt]
    frame llvm#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt]
    frame llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]
augusto2112 pushed a commit to augusto2112/llvm-project that referenced this issue Jan 23, 2023
@adrian-prantl
Work around an infinite recursion with deadlock that only exists on
a8339d3 
the swift branch.

The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb.

One thing it does is resolve any unresolved global symbols in the JIT
module. This global search can cause the JIT module to recursively be
asked for its symtab.

This patch works around the problem by removing the JIT module from
the list of modules being searched while in PopulateSymtab. That isn't
done in the most elegant fashion, as it does so by changing the state
of the IRExecutionUnit object.

(lldb) bt
* thread llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame llvm#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame llvm#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame llvm#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame llvm#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt]
    frame llvm#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt]
    frame llvm#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt]
    frame llvm#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt]
    frame llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame llvm#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt]
    frame llvm#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt]
    frame llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame llvm#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt]
    frame llvm#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt]
    frame llvm#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt]
    frame llvm#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt]
    frame llvm#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt]
    frame llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame llvm#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame llvm#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame llvm#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame llvm#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame llvm#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt]
    frame llvm#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt]
    frame llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame llvm#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt]
    frame llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame llvm#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt]
    frame llvm#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt]
    frame llvm#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt]
    frame llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]

(cherry picked from commit ba81700)
@fel-cab fel-cab mentioned this issue Feb 8, 2023
Open
@raidenluikang raidenluikang mentioned this issue Feb 17, 2023
Closed
tarunprabhu referenced this issue in tarunprabhu/kitsune Apr 4, 2023
@neboat @tarunprabhu
[BitcodeReader] Fixing bug that caused BitcodeReader to fail to proce…
fc8ad8f 
…ss Tapir sync instructions correctly. This change addresses issue lanl#56.
Michael137 added a commit to Michael137/llvm-project that referenced this issue May 5, 2023
@Michael137
[lldb][TypeSystem] ForEach: Don't hold the TypeSystemMap lock across …
dda3a6a 
…callback

The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.

`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:

```

int main() {
    std::unique_ptr<int> up = std::make_unique<int>(5);

    volatile int val = *up;
    return val;
}

clang++ -std=c++2a -g -O1 main.cpp

./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```

```
frame llvm#4: std::lock_guard<std::mutex>::lock_guard
frame llvm#5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock llvm#2
frame llvm#6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame llvm#7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame llvm#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame llvm#27: lldb_private::SwiftASTContext::LoadModule
frame llvm#30: swift::ModuleDecl::collectLinkLibraries
frame llvm#31: lldb_private::SwiftASTContext::LoadModule
frame llvm#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame llvm#35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame llvm#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame llvm#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame llvm#38: lldb_private::Target::GetPersistentSymbol
frame llvm#41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock llvm#1
frame llvm#42: lldb_private::Target::GetPersistentSymbol
frame llvm#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame llvm#44: lldb_private::IRExecutionUnit::FindSymbol
frame llvm#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame llvm#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#48: llvm::LinkingSymbolResolver::findSymbol
frame llvm#49: llvm::LegacyJITSymbolResolver::lookup
frame llvm#50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame llvm#51: llvm::RuntimeDyldImpl::resolveRelocations
frame llvm#52: llvm::MCJIT::finalizeLoadedModules
frame llvm#53: llvm::MCJIT::finalizeObject
frame llvm#54: lldb_private::IRExecutionUnit::ReportAllocations
frame llvm#55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame llvm#56: lldb_private::ClangExpressionParser::PrepareForExecution
frame llvm#57: lldb_private::ClangUserExpression::TryParse
frame llvm#58: lldb_private::ClangUserExpression::Parse
```

Our solution is to simply iterate over a local copy of `m_map`.

**Testing**

* Confirmed on manual reproducer (would reproduce 100% of the time
  before the patch)

Differential Revision: https://reviews.llvm.org/D149949
@hubzhangxj hubzhangxj mentioned this issue Oct 28, 2023
Closed
searlmc1 referenced this issue in ROCm/llvm-project Nov 27, 2023
@yxsamliu
Stop hipcc from passing --hip-device-lib-path (#56)
e8a4f17 
to clang by default.

Let clang determine device lib path by itself by default.

Only do that if env var DEVICE_LIB_PATH is set.

Change-Id: I403cf3e6a10215f85871f9dad79cd57f67395e59
@christiandaley christiandaley mentioned this issue Jan 26, 2024
Closed
@paveltrpn paveltrpn mentioned this issue Feb 18, 2024
Open
@Neojan Neojan mentioned this issue Mar 6, 2024
Closed
zhanyi22333 pushed a commit to zhanyi22333/llvm-project that referenced this issue Mar 7, 2024
@imkiva
[Clang][XTHeadVector] Add vector unit-stride segment load/store intri…
220cd17 
…nsics (llvm#56)

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>ff_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf><b/h/w>_v`

* [Clang][XTHeadVector] Fix Unit-stride segment load

* [Clang][XTHeadVector] Test Unit-stride segment load

* [Clang][XTHeadVector] Add Unit-stride segment store

* [Clang][XTHeadVector] Test Unit-stride segment store

* [NFC][XTHeadVector] Update README
mjklemm pushed a commit to mjklemm/llvm-project that referenced this issue Mar 28, 2024
@jsjodin
[MLIR][OpenMP] Updated fix for intermixed TargetDataOp and TargetOp (l…
d5bf7d3 
…lvm#56)

* [MLIR][OpenMP] Updated fix for intermixed TargetDataOp and TargetOp

* Update mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Remove extra newline
RevySR pushed a commit to revyos/llvm-project that referenced this issue Apr 3, 2024
@imkiva @RevySR
[Clang][XTHeadVector] Add vector unit-stride segment load/store intri…
6faac9d 
…nsics (llvm#56)

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>ff_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf><b/h/w>_v`

* [Clang][XTHeadVector] Fix Unit-stride segment load

* [Clang][XTHeadVector] Test Unit-stride segment load

* [Clang][XTHeadVector] Add Unit-stride segment store

* [Clang][XTHeadVector] Test Unit-stride segment store

* [NFC][XTHeadVector] Update README
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Apr 21, 2024
@ParkHanbum
[AArch64] Replace AND with LSL#2 for LDR target (llvm#34101)
feebf12 
Currently, process of replacing bitwise operations consisting of
`LSR`/`LSL` with `And` is performed by `DAGCombiner`.

However, in certain cases, the `AND` generated by this process
can be removed.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `SHIFTING` + `AND` operation on load
target can be optimized and optimizes it if it can.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Apr 21, 2024
@ParkHanbum
[AArch64] Replace AND with LSL#2 for LDR target (llvm#34101)
c8ee27e 
Currently, process of replacing bitwise operations consisting of
`LSR`/`LSL` with `And` is performed by `DAGCombiner`.

However, in certain cases, the `AND` generated by this process
can be removed.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `SHIFTING` + `AND` operation on load
target can be optimized and optimizes it if it can.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Apr 22, 2024
@ParkHanbum
[AArch64] Replace AND with LSL#2 for LDR target
7b5e856 
Currently, process of replacing bitwise operations consisting of
`LSR`/`LSL` with `And` is performed by `DAGCombiner`.

However, in certain cases, the `AND` generated by this process
can be removed.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `SHIFTING` + `AND` operation on load
target can be optimized and optimizes it if it can.
@nilres nilres mentioned this issue May 28, 2024
Closed
@ahatanak ahatanak mentioned this issue May 28, 2024
Closed
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue May 31, 2024
@ParkHanbum
[AArch64] Prevent change shl 2 to And for Load target
1343794 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue May 31, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
378b159 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Jun 1, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
5f02043 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Jun 3, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
95479a5 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Jun 3, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
a9fa7ec 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Jun 4, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
b518518 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Jun 6, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
b380592 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
@Alcaro Alcaro mentioned this issue Jun 7, 2024
Open
@llvmbot llvmbot mentioned this issue Jul 5, 2024
Open
@bluecorvetteai bluecorvetteai mentioned this issue Jul 12, 2024
Open
faisalv pushed a commit to faisalv/llvm-project that referenced this issue Jul 12, 2024
@delimbetov
Issue llvm#45: Implement is_noexcept meta function (llvm#56)
cbc95f8
RevySR pushed a commit to revyos/llvm-project that referenced this issue Jul 27, 2024
@imkiva
[Clang][XTHeadVector] Add vector unit-stride segment load/store intri…
b2f9c97 
…nsics (llvm#56)

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf>e<eew>ff_v`

* [Clang][XTHeadVector] Add `th_vlseg<nf><b/h/w>_v`

* [Clang][XTHeadVector] Fix Unit-stride segment load

* [Clang][XTHeadVector] Test Unit-stride segment load

* [Clang][XTHeadVector] Add Unit-stride segment store

* [Clang][XTHeadVector] Test Unit-stride segment store

* [NFC][XTHeadVector] Update README
ParkHanbum added a commit to ParkHanbum/llvm-project that referenced this issue Aug 21, 2024
@ParkHanbum
[AArch64] prevent (shl (srl x, c1), c2) -> (and (shift x, c3)) when load
c956250 
Currently, process of replacing bitwise operations consisting of
`(shl (srl x, c1), c2)` with `And` is performed by `DAGCombiner`.

However, in certain case like `(shl (srl, x, c1) 2)` is do not
need to transform to `AND` if it was used to `Load` Target.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `(shl (srl x, c1) 2)` operation on
`load` target can be prevent transform to `And`.
davemgreen pushed a commit that referenced this issue Aug 24, 2024
@ParkHanbum
[AArch64] Replace AND with LSL#2 for LDR target (#34101) (#89531)
77fccb3 
Currently, process of replacing bitwise operations consisting of
`LSR`/`LSL` with `And` is performed by `DAGCombiner`.

However, in certain cases, the `AND` generated by this process
can be removed.

Consider following case:
```
        lsr x8, x8, #56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL #2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, #58
        ldr w0, [x2, x8, lsl #2]
        ret
```

This patch checks to see if the `SHIFTING` + `AND` operation on load
target can be optimized and optimizes it if it can.
@hnarkaytis hnarkaytis mentioned this issue Aug 27, 2024
Open
dmpolukhin pushed a commit to dmpolukhin/llvm-project that referenced this issue Sep 2, 2024
@ParkHanbum @dmpolukhin
[AArch64] Replace AND with LSL#2 for LDR target (llvm#34101) (llvm#89531
16f04d7 
)

Currently, process of replacing bitwise operations consisting of
`LSR`/`LSL` with `And` is performed by `DAGCombiner`.

However, in certain cases, the `AND` generated by this process
can be removed.

Consider following case:
```
        lsr x8, x8, llvm#56
        and x8, x8, #0xfc
        ldr w0, [x2, x8]
        ret
```

In this case, we can remove the `AND` by changing the target of `LDR`
to `[X2, X8, LSL llvm#2]` and right-shifting amount change to 56 to 58.

after changed:
```
        lsr x8, x8, llvm#58
        ldr w0, [x2, x8, lsl llvm#2]
        ret
```

This patch checks to see if the `SHIFTING` + `AND` operation on load
target can be optimized and optimizes it if it can.
@usx95 usx95 mentioned this issue Sep 6, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation question A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jyknight @joker-eph @dcci @bwendling @lanistor