similar to: [LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp

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;

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

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

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

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

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

Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const

On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote: > Hi Daniel, > > I presume you mean, instead of assigning function arguments distinct ranks > (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we > should group function arguments in favor of existing pairings. Existing = pairings reassociate already chose before *not* existing

Ok. I'm basically just following the model of the other fast-isel ports. On 01/30/2015 09:12 PM, David Blaikie wrote: > (I'm assuming you're building LLVM with clang, in this case?) > > Looks like IntrinsicInst is one of those "lies" in LLVM that works via > type punning that's undefined behavior in C++, so it's code that > should be fixed anyway.

(I'm assuming you're building LLVM with clang, in this case?) Looks like IntrinsicInst is one of those "lies" in LLVM that works via type punning that's undefined behavior in C++, so it's code that should be fixed anyway. In any case, the reason this produces the debugging experience you're seeing is that LLVM (& GCC, for that matter) assumes that if your class

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote: > Ok. > > I'm basically just following the model of the other fast-isel ports. > Yeah, not your fault - just an architectural quirk. It's possible we could workaround the debug info side of this by declaring the virtual dtor (or some other virtual function - even an explicit anchor as we have

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent:

Attached please find the gdb backtrace dump and the postscript file of the DAG right before assertion. The red Node is the current Node in LegalizeOp() The only thing that I am customizing before we get here is the FORMAL_ARGUMENTS. At this time I don't really care about the arguments, just want to get some global values working. When I trace the program, it is well passed the legalizing of

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

Hi Micah, > I'm looking at the Legalize code and in 2.5 the above function is: >... > It seems to me that it was switched from a binary function expansion to > a unary function expansion. I don't understand the question. The new code is supposed to do exactly the same thing as the old code. Can you please be more explicit about what you think the problem is. > Is my