similar to: [LLVMdev] Debug Info Question

Sachin, On Feb 24, 2009, at 12:27 AM, Sachin.Punyani at microchip.com wrote: > Hi, > > I want to emit the debug information in assembly through assembler > directives. Also I don’t want to emit debug information in sections > (like Dwarf). Instead the debug information will be interspersed > with the assembly. However in LLVM, debug info (e.g. stoppoint) is > read

Hi, I want to emit the debug information in assembly through assembler directives. Also I don't want to emit debug information in sections (like Dwarf). Instead the debug information will be interspersed with the assembly. However in LLVM, debug info (e.g. stoppoint) is read and made part of the DAG only when DwarfWriter is registered. How can I emit the debug information in assembly

Hi, Probably I did not mention my question correctly. I need to emit declarations of the libcalls (that are made in the current module) at the beginning of the assembly file. The class "Module" does not maintain any list of the libcalls made during the program. Although, it maintains lists of all the global variables and functions in the current module. Traversing each

Hi Lang, Thanks for your inputs on the problem. I was just curious to know if you got any opportunity to work on the solution for this. Regards Sachin > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sachin.Punyani at microchip.com > Sent: Tuesday, November 17, 2009 12:00 PM > Subject: Re: [LLVMdev] Crash

Hi Sachin, llvm-dev, I've just committed a new PBQP solver which, among other things, should take care of this bug. Please let me know how it works out for you. Cheers, Lang. On Tue, Dec 15, 2009 at 5:54 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Sachin, > > Yes. Bernhard Scholz and I have just discussed a fix for this. I hope to > commit it in the next few days. I

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Bill Wendling > Sent: Friday, September 19, 2008 4:38 AM > > On Thu, Sep 18, 2008 at 7:12 AM, <Sachin.Punyani at microchip.com> wrote: > > What changes would be required in LLVM to support illegal pointer type? > > > Hi Sachin, >

Hi Sachin, Yes. Bernhard Scholz and I have just discussed a fix for this. I hope to commit it in the next few days. I will let you know as soon as it goes in to the mainline. Regards, Lang. On Tue, Dec 15, 2009 at 5:34 PM, <Sachin.Punyani at microchip.com> wrote: > Hi Lang, > > Thanks for your inputs on the problem. I was just curious to know if you > got any opportunity to

Hi Sachin, The declaration of functions called via the "call" instruction is a GlobalValue in your Module. You can go through all of the GlobalValues, look for those that are Function declarations (use the "Function::isDeclaration()" method), and then placing them in the appropriate place in your assembly file. Would that work? -bw On Jan 28, 2009, at 12:23 AM,

Hi Sachin, Confirmed: This is being caused by a subtle issue in the heuristic PBQP solver. Specifically: R1/R2 reductions as currently implemented can, on rare occasions, lead to the heuristic solver failing to find a finite cost solution, even though one exists. The infinite cost solution will always be in violation of some rule of register allocation (failing to handle an interference, or

Thanks Lang! I think we can use linear scan as work around for short term. Thanks for your help. Regards Sachin > -----Original Message----- > From: Lang Hames [mailto:lhames at gmail.com] > Sent: Sunday, November 15, 2009 10:08 AM > To: Sachin Punyani - I00202 > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Crash in PBQP register allocator > > Hi Sachin, >

> Hi Sachin, > > The declaration of functions called via the "call" instruction is a > GlobalValue in your Module. You can go through all of the > GlobalValues, look for those that are Function declarations (use the > "Function::isDeclaration()" method), and then placing them in the > appropriate place in your assembly file. > > Would that work? Hi

I am assuming a 16-bit value will be stored in a pair of 8-bit registers? If so, add pseudo register which represent pairs of 8-bit registers. Add them to a pseudo register class. This allows you to mark i16 "legal". The difficult part is then to figure out how to lower these 16-bit operations into 8-bit ones. You probably need to custom lower a bunch of them with target

>I am assuming a 16-bit value will be stored in a pair of 8-bit > registers? One related question is how to make sure that the correct register pair is allocated to the16-bit quantity when using two 8-bit operations. In other words, how we can make sure that the 16-bit pointer is stored into [AH, AL] and not in [AH, BL] ? i.e. GR8 = [ AH, BH, AL, BL]; GR16 = [AX, BX] ; // AX, BX

Hi, What changes would be required in LLVM to support illegal pointer type? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080918/36e53cde/attachment.html>

On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: > On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && > > "Invalid operand expansion"); > > > > LOAD node has two values but the assertion checks N->getNumValues() == 1 >

Hi All, I need to print some extra information about libcall names in assembly. Libcall names are managed as ExternalSymbols in LLVM. How do I access these ExternalSymbols from Asmprinter? AsmPrinter uses class Module that lists all the global variables (including extern variables) and functions (include extern functions). But it does not list any information about the libcalls

Hi, When expanding multiply operation in LegalizeTypes LLVM generates some nodes such as UMUL_LOHI (please refer file LegalizeIntegerTypes.cpp - function - ExpandIntegerResult). However while lowering this operation in LegalizeDAG (please refer file LegalizeDAG.cpp - function - LegalizeOp) the comment says "These nodes will only be produced by target-specific lowering.....".

Hi, Please see the two ".ll' files attached. Command line used llc -march=pic16 -pre-RA-sched=list-burr -regalloc=pbqp new.obc The above test case crashes only when I use the combination of list-burr scheduler and pbqp register allocator. If any of them (scheduler or register allocator) is replaced with some alternate then I don't see the crash. I could not figure

Can we help in local variable debug info work. Dale Johannesen wrote: > On Apr 7, 2009, at 9:52 PMPDT, vasudev wrote: > > >> Thanks for the info regarding DebugLoc field. Another related >> question >> that I have is regarding debug info for local variables. With -fast >> option, ISD::DECLARE nodes are created in DAG for debug info of local >>

On Thu, Sep 18, 2008 at 7:12 AM, <Sachin.Punyani at microchip.com> wrote: > What changes would be required in LLVM to support illegal pointer type? > Hi Sachin, The question's a bit broad. And I don't think the answer you want is as simple as "don't run the legalizer" (which probably won't work). Do you have a more specific question? -bw