search for: legalizefloattypes

Displaying 17 results from an estimated 17 matches for "legalizefloattypes".

2009 Apr 08
0
[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 exactly the same thing as the old code. Can you please be more explicit about what you think the problem is. > Is my
2009 Apr 08
1
[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
2009 Apr 08
2
[LLVMdev] LegalizeFloatType:ExpandFloatRes_FADD
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,
2009 Sep 29
2
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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 =
2009 Sep 29
0
[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;
2009 Sep 29
2
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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
2009 Sep 30
0
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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
2009 Oct 05
0
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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
2009 Dec 25
1
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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
2009 Oct 05
2
[LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
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
2009 Apr 08
0
[LLVMdev] What is the state of LLVM's ARM backend
...> > 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 f...
2009 Apr 08
4
[LLVMdev] What is the state of LLVM's ARM backend
..._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 '@e...
2009 Apr 08
2
[LLVMdev] What is the state of LLVM's ARM backend
...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 Selecti...
2009 Apr 01
0
[LLVMdev] What is the state of LLVM's ARM backend
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
2009 Apr 01
4
[LLVMdev] What is the state of LLVM's ARM backend
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
2012 Oct 19
3
[LLVMdev] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes
...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/Code...
2015 Jul 29
1
[LLVMdev] Error when i am using command make -j4 command in cygwin to compile safecode
...]: 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 LegalizeIn...