similar to: Help in generating Debug symbols

Hi Florian, Thanks for the reply. On Fri, Dec 8, 2017 at 6:48 PM, Florian Hahn <florian.hahn at arm.com> wrote: > Hi, > > On 08/12/2017 06:24, Nagaraju Mekala via llvm-dev wrote: >> >> Hi all, >> >> I am new to LLVM. Currently working on adding an embedded target to >> LLVM backend. >> I was able to generate the object file for our

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List

On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dblaikie at gmail.com> wrote: > > Yeah, not sure - you mention the linker produces errors, but the errors you showed looked like objdump errors? Were those errors from trying to dump the linked executable, and not errors that were produced by the linker itself? Yes, as mentioned earlier I was able to generate final executable but it

Hi James, Thanks for reply. When I looked in to the generated debug dump from the object file I found that DW_AT_name is always (indirect string, offset: 0x0): clang version 8.0.1, instead of variable names. Below is a sample output of the debug dump. Compilation Unit @ offset 0x0: Length: 0x6a (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4

On Saturday, April 18, 2020, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello All, >> >> I was trying to add Microblaze target to LLVM backend. I was able to >> generate object file with relocations. and debug symbols. >>

Hi All, I am working on a target which requires to generated two instructions for a single branch instruction. ex: imm 1 br r4,0xabcd branch address is 0x1abcd, imm has the upper 16 bits and br has lower 16 bits. Can anyone let me know how to write these kind of patterns in the InstrInfo.td file. Thanks in Advance, Nagaraju

On Fri, Mar 2, 2018 at 4:59 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I am working on a target which requires to generated two >> instructions for a single branch instruction. >> ex: >> imm 1 >> br r4,0xabcd >> branch

Hello All, I was trying to add Microblaze target to LLVM backend. I was able to generate object file with relocations. and debug symbols. When I try to link this object file with microblaze GCC linker I am getting below errors and debug symbols are missing in it. mb-objdump: DWARF error: found dwarf version '15877', this reader only handles version 2, 3, 4 and 5 information

Other suggestions 1/ Write a separate MI pass to split the macro MI which was generated earlier as a result of ISel to multiple MIs. 2/ Take the decision of splitting later in the pipeling during MC lowering. Decision about when you need to split should be driven by your intent to do any further processing over constituent instruction. ~ Jatin On Fri, Mar 2, 2018 at 8:19 PM, Jatin Bhateja

Hi Nagaraju, Few suggestions split this into following steps. 1/ DAG Legalization : Custom lower the instruction (branch in your case) appropriately in legalization to target specific DAG nodes and glue the nodes together which you want scheduler should schedule together. 2/ Instruction Selection : Define patterns to match the custom DAG nodes. Thus actual decision of creating multiple

On 2 Mar 2018, at 11:45, Nagaraju Mekala <nagaraju.mekala87 at gmail.com> wrote: > > yes they are dependent if the branch immediate value is > 0xffff then > the imm instruction should generate other wise only "br" instruction > is enough. This sounds as if you have two br instructions, one that takes an immediate and one that takes a register and requires that

On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am working on a target which requires to generated two > instructions for a single branch instruction. > ex: > imm 1 > br r4,0xabcd > branch address is 0x1abcd, imm has the upper 16 bits and br has > lower 16 bits. > > Can anyone let me know how to write

Hi Florian, Ok, I ran this: cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode Compiled it again from clean, and the situation is worse than before. Incremental builds take an incredible amount of time stuck in running Tablegen scripts for all targets. Now this happens both in Release and Debug configurations. Just before this, at least Release compiled fine, but

Hi, On 12/04/2018 15:35, Frozen via llvm-dev wrote: > I added one attribute named EndLine in LLVM IR before. LLVM's part is > not hard, but will modify many places in Clang. I success for it, you > can try this way. > For loops, we use a range to keep track of the start and end of the loop for remarks: http://llvm.org/doxygen/classllvm_1_1Loop_1_1LocRange.html Maybe it would

Hi Praveen, Please, can you elaborate on this?. What do do mean by “building as shared objects”. Thanks, John > On 30 Jun 2019, at 07:32, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Maybe try building llvm as a shared objects.. > > On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Rather than “fixing” it, it might be better to support a separate method for signed extension. My reasoning is as follows: int x = 7; llvm::PointerIntPair<double*, 3, int> pip; pip.setInt(x); There could be code out there that expects pip.getInt() to return 7 and not -1. So if you really want to set a negative and return a negative value, a separate method setSignedInt and getSignedInt

Hello All, This conversations seems to have fizzled out and I would like to try to revive it. My intention is to pick up where Graham left off with enabling partial-inlining by default. On Sat, Dec 9, 2017 at 7:47 AM, Florian Hahn via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On 13/11/2017 14:47, Evgeny Astigeevich via llvm-dev wrote: > >> Hi Graham,

It won't move the sign bit, so negative values won't fit, unless you have a 3 bit signed type ;) Note that if you assign negative values to and then read from a signed bit-field, you would do sign extension. So 3-bit signed types do exist in C++. It begs the question why PointerIntPair supports signed int types if it always loses the sign. Is it just to avoid signed/unsigned comparison

I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and less error prone for the user to write the sign extension if they want it. By extension, it seems good that PointerIntPair doesn't do sign extension when the type happens to be signed. On Wed, Apr 4, 2018 at 9:47 AM David Blaikie via llvm-dev < llvm-dev at