similar to: [LLVMdev] Call argument split

>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

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

Hi All, I have some doubt in LLVM Type Legalizer. How will LOAD:i8 with an i16 operand be lowered in type legalizer? (i16 type is not legal for our target) Following assertion in function ExpandIntegerOperand (file LegalizeIntegerTypes.cpp) is not allowing us to change LOAD node. assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 &&

> -----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, > > 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

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 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, 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

On Wed, Dec 17, 2008 at 11:49 PM, <Sachin.Punyani at microchip.com> wrote: > 2) Why is custom legalization of this node not allowed? No target has needed it so far. Why do you need it? > 3) My target does not have any instruction directly matching to this > operation. How should this node be legalized? If your target doesn't have this operation, you should mark

Hi I am sorry. In my previous mail I mistyped the test case and disassembly. Test case -- -------------------------------------- char a; char fun () { return a; } -------------------------------------- Disassembly -------------------------------------- ; ModuleID = 'first.bc' @a = global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry: %tmp = load i8* @a ; <i8>

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 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

See MachineOperand.h. If a MachineOperand represents an external symbol, getSymbolName() returns a string. Evan On Jan 27, 2009, at 8:26 PM, Sachin.Punyani at microchip.com wrote: > 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

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

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

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, 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

Hi All, Please consider the following case Test case -- -------------------------------------- char a; void fun () { return a; } -------------------------------------- Following disassembly (using llvm-dis) is generated for the above test case -------------------------------------- ; ModuleID = 'first.bc' @a = internal global i8 0 ; <i8*> [#uses=1] define i8 @fun(...) { entry:

Hi Lang, I'm surprised about the fact that you omit R1/R2 reductions in some cases. Can you give a more detailed description of the bug (e.g. a PBQP dump)? Best regards, Sebastian Lang Hames wrote: > 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.

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