search for: legalizefloattype

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

...hat MakeLibCall was the same in both Cases but instead it uses LibCallify instead. Sorry for the mistake, Micah -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Wednesday, April 08, 2009 12:25 PM To: llvmdev at cs.uiuc.edu Cc: Villmow, Micah Subject: Re: [LLVMdev] LegalizeFloatType:ExpandFloatRes_FADD 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 exa...

I'm looking at the Legalize code and in 2.5 the above function is: void DAGTypeLegalizer::ExpandFloatRes_FADD(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Call = LibCallify(GetFPLibCall(N->getValueType(0), RTLIB::ADD_F32, RTLIB::ADD_F64,

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 =

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

...> > root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc > SoftenFloatResult #0: 0x614e00: f32 = undef > llc: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.6-r0/llvm-2.6/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:54: void llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int): Assertion `0 && "Do not know how to soften the result of this operator!"' failed. > Stack dump: > 0. Program arguments: llc > 1. Running pass 'ARM Instruction Selection' on...

..._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: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.6-r0/llvm-2.6/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:54: void llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int): Assertion `0 && "Do not know how to soften the result of this operator!"' failed. Stack dump: 0. Program arguments: llc 1. Running pass 'ARM Instruction Selection' on function '@...

...t; root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >> SoftenFloatResult #0: 0x614e00: f32 = undef >> llc: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.6-r0/llvm-2.6/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:54: void llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int): Assertion `0 && "Do not know how to soften the result of this operator!"' failed. >> Stack dump: >> 0. Program arguments: llc >> 1. Running pass 'ARM Instruction Select...

LLVM ARM v6 backend is in fairly good shape. Even the JIT passes nearly the entire llvm test suite. There are some known missing bits: 1. Exception handling 2. Atomic Not sure: 3. Debugging support (should be trivial to hook up if it's not done) Also the thumb backend is not awesome. Its performance is not great. Evan On Apr 1, 2009, at 6:34 AM, Robert Schuster wrote: > Hi, > the

Hi, the ARM backend lacks some stuff like support for atomic intrinsics. I learned the hard way (crash). Lately I was told that the ARM backend of LLVM is generally in its early stages of development. I would like to know more about this. Which stuff is missing, known to be unstable and the like. Thanks in advance for taking the time. Regards Robert -------------- next part -------------- A

...Function.cpp | 2 +- lib/CodeGen/SelectionDAG/DAGCombiner.cpp | 58 +++++++++++++++++++++++++++++++++------------------------- lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | 63 ++++++++++++++++++++++++++++++++++----------------------------- lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp | 4 ++-- lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp | 18 +++++++++--------- lib/CodeGen/SelectionDAG/LegalizeTypes.cpp | 2 +- lib/CodeGen/SelectionDAG/LegalizeTypesGeneric.cpp | 12 ++++++------ lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp | 14 +++++++------- lib/Cod...

...]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Target' make[3]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Target/X86' llvm[3]: Building X86.td register info implementation with tblgen llvm[3]: Compiling LCSSA.cpp for Release+Asserts build llvm[3]: Compiling LegalizeFloatTypes.cpp for Release+Asserts build llvm[2]: Compiling DominanceFrontier.cpp for Release+Asserts build llvm[3]: Building X86.td instruction information with tblgen llvm[2]: Compiling IVUsers.cpp for Release+Asserts build llvm[3]: Compiling Local.cpp for Release+Asserts build llvm[3]: Compiling LegalizeI...