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

Did llvm support ARM based platform analysis? Where could I download the compiler supporting ARM? #68

Closed
boofish opened this issue Dec 18, 2019 · 2 comments
Closed

Did llvm support ARM based platform analysis? Where could I download the compiler supporting ARM? #68

boofish opened this issue Dec 18, 2019 · 2 comments

Comments

@boofish
Copy link

boofish commented Dec 18, 2019 •
edited

Hi, I want to do some analysis based on ARM architecture, but I do not find the tools used to generated ARM platform IR, could anyone give me help? Thanks.
@TNorthover
Copy link
Contributor

You have to go out of your way to produce a version of LLVM that won't compile for ARM.

On Linux you should just be able to run "clang -target armv7-linux-gnueabihf -emit-llvm -S -o - file.c" to produce the ARM IR. It'll be using the x86 headers though, which you might want to fix by installing an ARM sysroot eventually.

On macOS, you could run "clang -arch armv7k -emit-llvm -S -o - file.c" instead. That will already be using appropriate headers (for the watch).

@boofish
Copy link
Author

boofish commented Dec 20, 2019

Wow, that is what I want, Thank you!

@boofish boofish closed this as completed Dec 20, 2019
madscientist159 referenced this issue in madscientist159/llvm-project Jan 13, 2020
@ronlieb
remove us of malloc for nested_parallel (ROCm#68)
8664698 
* remove use of malloc for nested_parallel

. clang determines number of nested parallels per kernel
. level passed through the KernelDescriptor
. plugin rtl.cpp computes Teams*Threads*Levels just before launch
  and allocates memory for the callStack.
. serialized_parallel grabs its assigned omptarget_nvptx_TaskDescr item

Footnote: There are still uses of SafeMalloc in the runtimes.
  Tasks, data_env, and shared_args > MAX_SHARED_ARGS still use
  SafeMalloc which calls __malloc.

* undo bandaid growth of heap: 5000 -> 64, and increase MAX_SHARED_ARGS from 20 to 40 to eliminate SNAPs need for the 5000 heap bandaid.

* use more portable APIs for thread, block, group...

* Add warning for nested parallel, and restore use of SafeMalloc/SafeFree for non amdgcn build
@siggi-alpheus siggi-alpheus mentioned this issue Apr 5, 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
@jharvell jharvell mentioned this issue May 7, 2023
Closed
@Bouncner Bouncner mentioned this issue Jun 12, 2023
Closed
searlmc1 referenced this issue in ROCm/llvm-project Aug 23, 2023
@david-salinas
Merge pull request #68 from david-salinas/update-jenkins-for-clr-repo
d65e8f0 
Update Jenkinsfile by adding CLR repository
@llvmbot llvmbot mentioned this issue Sep 15, 2023
Closed
jeffreytan81 pushed a commit to jeffreytan81/llvm-project that referenced this issue Sep 21, 2023
Lazy deference underlying object for shared/weak/unique_ptr synthetic…
64e7184 
… provider

We noticed some performance issue while in lldb-vscode for grabing the name of the SBValue.
Profiling shows SBValue::GetName() can cause synthetic children provider of shared/unique_ptr
to deference underlying object and complete it type.

This patch lazily moves the dereference from synthetic child provider's Update() method to
GetChildAtIndex() so that SBValue::GetName() won't trigger the slow code path.

Here is the culprit slow code path:
```
...
frame llvm#59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame llvm#67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame llvm#68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame llvm#69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame llvm#78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame llvm#79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame llvm#80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame llvm#81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame llvm#82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame llvm#83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```

Differential Revision: https://reviews.llvm.org/D159542
jeffreytan81 pushed a commit that referenced this issue Sep 21, 2023
Lazy deference underlying object for shared/weak/unique_ptr synthetic… (
9faf8b5 
#67069)

We noticed some performance issue while in lldb-vscode for grabing the
name of the SBValue. Profiling shows SBValue::GetName() can cause
synthetic children provider of shared/unique_ptr to deference underlying
object and complete it type.

This patch lazily moves the dereference from synthetic child provider's
Update() method to GetChildAtIndex() so that SBValue::GetName() won't
trigger the slow code path.

Here is the culprit slow code path:
```
...
frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```

Differential Revision: https://reviews.llvm.org/D159542
@paveltrpn paveltrpn mentioned this issue Feb 18, 2024
Open
@nilres nilres mentioned this issue May 28, 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
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@TNorthover @boofish