similar to: [LLVMdev] [lld] How do I prevent .note sections from being eliminated?

Displaying 20 results from an estimated 110 matches similar to: "[LLVMdev] [lld] How do I prevent .note sections from being eliminated?"

2015 Jun 15
2
[LLVMdev] [lld] How do I prevent .note sections from being eliminated?
On Sat, Jun 13, 2015 at 01:08:50PM +0300, Simon Atanasyan wrote: > Hi, > > If you need to control content of output .note section, take a look at > ARMExidxSection, MipsReginfoSection, MipsOptionsSection classes. If > you need to copy sections from input to output, use SDataSection (from > Hexagon) as a reference point. > Hi Simon, Thanks for the reply. I have a few more
2014 Feb 26
2
[LLVMdev] [lld] Relocation reading refactoring
Hi, Thanks for the explanation. If I understand you properly you suggest to move relocation parsing to the class with the following interface. Right? Who will be user of this class? If it is still only ELFFile class, what benefits will we get from separation of this logic? template <class ELFT> class ELFRelocationReader { public: ELFRelocationReader(.....); // Returns all created
2014 Mar 06
2
[LLVMdev] [lld] Relocation reading refactoring
Hi Shankar, I almost implement ELFRelocationReader but still not completely sure that this is a right direction. Suppose somebody wants to override creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel` record. Let's consider two implementations A and B: A: ===== 1. Factor out `ELFReference` creation from `createDefinedAtomAndAssignRelocations` into a couple of virtual
2015 Jan 12
2
[LLVMdev] [lld] ARM/Thumb atom forming
Thanks, Shankar. I needed to override all the places where st_value had been used, and it worked. But there another problem appeared: after correcting all atoms, I cannot distinguish between ARM and Thumb symbols in the further stages when fixing up relocations. I used to check targetVAddress (in terms of the relocation handler) since it contained 1 in the least bit when addressing Thumb
2017 Dec 05
2
[LLD] Slow callstacks in gdb
Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote: >>> I will retry with clang trunk, when it reproduces I will build some >>> other >>> large project (that has DSOs) using our compile/link options (they are >>> not >>> that special, I think). >> >> If you can try lld trunk too that would be awesome.
2017 Dec 02
2
[LLD] Slow callstacks in gdb
Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote : >>> Maybe gdb needs to fall back to slower line number resolution because >>> e.g. >>> low and high bounds cannot be retrieved and debug_line_address is 0? >> >> It is hard to know without a reproducible. I tried gdb on clang itself >> build with both clang and
2015 May 07
2
[LLVMdev] [lld] Wrong references for C++ COMDAT groups
Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596
2014 Feb 26
2
[LLVMdev] [lld] Relocation reading refactoring
Hi Shankar, On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Author: shankare > Date: Tue Feb 12 12:46:53 2013 > New Revision: 174990 > > URL: http://llvm.org/viewvc/llvm-project?rev=174990&view=rev [...] > ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef
2019 Mar 06
3
RFC: Adding "minidump" support to obj2yaml
Hello all, yesterday I sent an email <http://lists.llvm.org/pipermail/lldb-dev/2019-March/014811.html> to lldb-dev proposing a new tool in lldb for yamlization of minidump files. It's been suggested to me that instead of a new tool it may be better to add support for that format to obj2yaml instead. Hence, this email. :) As I expect most people are unfamiliar with this format, I'm
2007 Nov 08
3
[LLVMdev] Newbie JITter
Hi, I'm experimenting with using LLVM to generate dynamic FFI bridges in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from dynamically generated assembler source to machine code, and I have that all working, copied from the llc tool and the JIT example. I have two questions: 1. What optimization passes, if any, should I run on the module before I pass it to the
2007 Nov 09
0
[LLVMdev] Newbie JITter
On Nov 7, 2007, at 6:10 PM, Antony Blakey wrote: > Hi, > I'm experimenting with using LLVM to generate dynamic FFI bridges > in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from > dynamically generated assembler source to machine code, and I have > that all working, copied from the llc tool and the JIT example. I > have two questions: > > 1. What
2015 Apr 20
2
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
On 04/20/2015 01:25 PM, David Majnemer wrote: > These optimizations are not always run on IR that is fed to the backend. The DAG combiner also performs the undefined shift -> undef though, so it should still be OK -Matt
2020 Jun 12
3
Why doesn't this `and` get eliminated
define dso_local i32 @f(i32 %0) { %2 = and i32 %0, 7 %3 = icmp eq i32 %2, 7 %4 = zext i1 %3 to i32 ret i32 %4 } I thought instcombine would remove it. It doesn't and nothing else does either. LLVM Version is 10.0.0. /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL:
2015 Apr 20
3
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
For example: unsigned int x, y; void foo() { y = x >> 129; } Where int is a 16bit type, the .ll is producing only 'ret void' at O3. At O0 the .ll looks fine but then llc gets rid of it an simply returns. I'm just curious what the reasoning is for this? It isn't trying to set y to anything at all. Thanks. -------------- next part -------------- An HTML attachment was
2015 Apr 21
2
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to
2008 Nov 25
3
[Bug 562] Rule gets implicitly eliminated ("optimized away") --> But that's not ok --> A Logic Bug
http://bugzilla.netfilter.org/show_bug.cgi?id=562 kernel at linuxace.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kernel at linuxace.com Status|NEW |RESOLVED Resolution|
2010 Mar 31
1
Performance issues: have eliminated disk and network as cause
Hi, I'm not entirely happy with the performance I'm seeing using Samba, and I wonder if anyone can shine any light. The server is a Dell PowerEdge 2950 with hardware RAID10, 4GB RAM and a quad-core Intel Xeon processor. It's not live yet, so there's no load from other tasks. I've already eliminated the RAID (able to sustain 130-140MB/s for reads/writes) and the network
2015 Apr 20
3
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >
2016 Apr 20
2
[IndVarSimplify] Narrow IV's are not eliminated resulting in inefficient code
​Hi, Would you be able to kindly check and assist with the IndVarSimplify / SCEV problem I got in the latest LLVM, please? Sometimes IndVarSimplify may not eliminate narrow IV's when there actually exists such a possibility. This may affect other LLVM passes and result in inefficient code. The reproducing test 'indvar_test.cpp' is attached. The problem is with the second
2008 Nov 23
4
[Bug 562] New: Rule gets implicitly eliminated ("optimized away") --> But that's not ok --> A Logic Bug
http://bugzilla.netfilter.org/show_bug.cgi?id=562 Summary: Rule gets implicitly eliminated ("optimized away") --> But that's not ok --> A Logic Bug Product: iptables Version: unspecified Platform: x86_64 OS/Version: Debian GNU/Linux Status: NEW Severity: normal Priority: P2