similar to: [LLVMdev] Declarations for libcalls.

On Mon, 2009-10-05 at 16:54 -0700, Eli Friedman wrote: > On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > > Sanjiv Gupta wrote: > >> Sanjiv Gupta wrote: > >> > >>> Duncan Sands wrote: > >>> > >>> > >>>> Hi Sanjiv, I think a lot of the softening code assumes you are

On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta <sanjiv.gupta at microchip.com> wrote: > Sanjiv Gupta wrote: >> Sanjiv Gupta wrote: >> >>> Duncan Sands wrote: >>> >>> >>>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>>> with float (32 bits).  So it's not just a matter of changing the libcall

Sanjiv Gupta wrote: > Sanjiv Gupta wrote: > >> Duncan Sands wrote: >> >> >>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>> with float (32 bits). So it's not just a matter of changing the libcall >>> return type. >>> >>> >>> >> Yes, we are dealing with 32-bits

Sanjiv Gupta wrote: > Duncan Sands wrote: > >> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >> with float (32 bits). So it's not just a matter of changing the libcall >> return type. >> >> > Yes, we are dealing with 32-bits only. But why the cmp libcalls have to > return a 32-bit value. > e.g. Our libcall for

Duncan Sands wrote: > Hi Sanjiv, I think a lot of the softening code assumes you are dealing > with float (32 bits). So it's not just a matter of changing the libcall > return type. > Yes, we are dealing with 32-bits only. But why the cmp libcalls have to return a 32-bit value. e.g. Our libcall for comparing two floats is char _eq_f32 (float a, float b); rather than long

How do I determine if an external symbol is meant for a libcall? Our AsmPrinter needs to print more information about libcalls, so we need to distinguish them from other ordinary external symbols. Thanks, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/a79356b5/attachment.html>

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

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

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

Jakob Stoklund Olesen wrote: > On 24/07/2009, at 19.41, <Alireza.Moshtaghi at microchip.com> wrote: > > >> As you know PIC16 does not have stack; so generating code for ISR and >> all functions that it calls (including all stdlib and basic math >> intrinsics used for mult/div/etc) requires special code generation >> techniques. But we don't have this

Hi Sanjiv, I think a lot of the softening code assumes you are dealing with float (32 bits). So it's not just a matter of changing the libcall return type. > While generating a libcall from floating point comparison, it always > assumes that the return type of those libcalls is i32. > Why not allow Targets to provide the correct return type? > > EVT RetVT = MVT::i32;

While generating a libcall from floating point comparison, it always assumes that the return type of those libcalls is i32. Why not allow Targets to provide the correct return type? EVT RetVT = MVT::i32; // <-- here SDValue Ops[2] = { LHSInt, RHSInt }; NewLHS = MakeLibCall(LC1, RetVT, Ops, 2, false/*sign irrelevant*/, dl); NewRHS = DAG.getConstant(0, RetVT); CCCode =

On Aug 27, 2009, at 7:44 PM, Sanjiv Gupta wrote: > Chris Lattner wrote: >> >>> We provide two sets of intrinsic functions in the port >>> specific library and appropriate function call will be generated >>> depending on whether we are in ISR or mainline code. The right way >>> of >>> doing this is to keep all the logic in legalizer - use the

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/18 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> Hi Mikhail, >> Thanks for your wonderful help so far. I have few more questions to ask: >> >> How do I modify the driver to pick tools from where the driver itself >> resides, rather than from the PATH? >> Do I need to write some C++ code

On Wed, Jul 15, 2009 at 7:29 PM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: > On Wed, 2009-07-15 at 10:37 -0700, Devang Patel wrote: >> On Wed, Jul 15, 2009 at 9:32 AM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: >> > Consider the example command line below >> > >> > $ llvm-ld -disable-opt hello.bc -l std -o hello.out >> >

Chris Lattner wrote: > >> We provide two sets of intrinsic functions in the port >> specific library and appropriate function call will be generated >> depending on whether we are in ISR or mainline code. The right way of >> doing this is to keep all the logic in legalizer - use the existing >> infrastructure and customize the library calls for each non-native

Mikhail Glushenkov wrote: > > Hi Sanjiv, > > Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes: > > > The salient features that we want to have in the driver are: > > [...] > > As promised, I've implemented a basic compiler driver for the > PIC16 toolchain. It's under tools/llvmc/examples/mcc16. > Hi Mikhail, How do you build mcc16