similar to: [LLVMdev] LegalizeFloatType:ExpandFloatRes_FADD

In the 2.4 code, it explicitly used 2 Operands to the MakeLibCall function, whereas in 2.5 it only uses 1 Operand. Other functions like pow, cos, sin, only use 1 Operand as I would expect since they are unary functions and div/mul uses two operands as expected. But after looking more closely at the code, I realized my Mistake in thinking that MakeLibCall was the same in both Cases but

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

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 Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > Hello, > > my target has libcall support for long long shifts. I already have the > following lines in my Lowering constructor: > >   setLibcallName(RTLIB::SHL_I64, "__llshl"); >   setLibcallName(RTLIB::SRL_I64, "__llshru"); >  

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

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

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

> Is i64 a legal type on your target? If so, you might need to hack the > code generator a bit; no in-tree target has a legal integer type that > doesn't support shifts. If not, I have no idea how you're getting > that error. Yes, well, i64 is a legal type, that's how it is. However, i64s are always stored in two 32-bit registers and in some cases need complicated

Johannes, Try a custom lowering of the 64bit shift instructions and then in the Lower[SRL|SHL|SRA] function, generate a call instruction to the function you want. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Johannes Birgmeier > Sent: Sunday, January 08, 2012 2:38 AM > To: llvmdev at cs.uiuc.edu

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

Hi Xerxes, > 4. softfloat related errors > http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ > example: > > root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc > SoftenFloatResult #0: 0x614e00: f32 = undef > llc: