search for: bit_convert

Attached is a patch that renames ISD::BIT_CONVERT to ISD::BITCAST as per http://www.llvm.org/OpenProjects.html, #3 under Code Generator Improvements. I have not updated the OpenProjects.html file itself as I could not find that file in the source code. The patch itself also includes elimination of whitespace at the end of lines because my VIM set...

On Nov 21, 2010, at 7:10 PM, Wesley Peck wrote: > Attached is a patch that renames ISD::BIT_CONVERT to ISD::BITCAST as per http://www.llvm.org/OpenProjects.html, #3 under Code Generator Improvements. I have not updated the OpenProjects.html file itself as I could not find that file in the source code. > > The patch itself also includes elimination of whitespace at the end of lines because...

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introducing il...

...g to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeti...

Hi Gabriele, > In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. > On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introduci...

...g to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. > I've tried a custom lowering function that lowers it to dst = sub 0, src0 > and forcing it to f32, but it complains that result and the...

Duncan: DAGCombine is inserting an IllegalOperation after target-specific instruction legalization has occurred. I'm inserting the fabs and the bitconvert during instruction legalization; DAGCombine is converting the fabs/bitconvert to an 'and' on its second (third?) pass. -scooter On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote: > On Tuesday 20 January 2009 07:52:37

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

...he final DAG more complex than before the combine step. This makes no sense. I plan to solve this problem by doing the reverse operation the combiner did. During selection (in SelectionDAGISel::Select()), I check for the node pattern having a i64 AND between an i64 constant 0x7FFFFFFFFFFFFFFF and a bit_convert, and I replace this by a fabs and a bit_convert node. In this way, this portion of the DAG will look as before the "combine 2" step. I think this is not so far from what Michel suggested. Have I to make a bug report ? Is there any predictable order on which all nodes are going through Sel...

...bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) { unsigned Align = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); unsigned OrigAlign = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAli...

...================================================ --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp (working copy) @@ -4903,9 +4903,9 @@ // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) { - unsigned Align = ST->getAlignment(); + unsigned OrigAlign = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); - unsigned OrigAlign = TLI.getTargetData()-> + unsigned Align =...

...g to pattern match on an i32 > when there are no i32's in my test program. With the regular SPARC backend, what ends up happening is the following: 1. The float is passed in an integer register (here's where the i32 first shows up) 2. The DAG combiner notices this, and combines the fneg(bit_convert(arg)) to bit_convert(xor(arg, sign_bit)). 3. The store of the bit_convert gets turned into an i32 store, and there are now no more floats in the code. I removed the SPARC pattern matching instructions for the fneg instruction because I don't want this behavior. The architecture I'm targeti...

.../ Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially generate libcalls, + // not to completely legalize vectors. Also, leaving these around + // exposes them to...

...nal DAG more complex than before the combine step. This makes no sense. > I plan to solve this problem by doing the reverse operation the combiner did. During selection (in SelectionDAGISel::Select()), I check for the node pattern having a i64 AND between an i64 constant 0x7FFFFFFFFFFFFFFF and a bit_convert, and I replace this by a fabs and a bit_convert node. In this way, this portion of the DAG will look as before the "combine 2" step. I think this is not so far from what Michel suggested. how about this instead: modify the DAGCombiner so that before operations have been legalized, the DA...

.../ Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially be unrolled to + // illegal types. Leaving them around can also help optimization. + break; + case ISD:...

...======================= > --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) > +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp (working copy) > @@ -4903,9 +4903,9 @@ > // resultant store does not need a higher alignment than the original. > if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && > ST->isUnindexed()) { > - unsigned Align = ST->getAlignment(); > + unsigned OrigAlign = ST->getAlignment(); > MVT SVT = Value.getOperand(0).getValueType(); > - unsigned OrigAlign = TLI.getTargetData()-&g...

I have started to add support for FP in the ARM backend. According to the ABI, 32 bit floating point numbers should be returned in R0 and 64bit ones in R0/R1. I have solved the 32 bit case by inserting bit_converts in LowerRET. For the 64bit case I considered two options: 1) Creating two nodes. fp_lo and fp_hi. I could then select fmrdh and fmrdl with (set IntRegs:$dst (bitconvert (fp_hi DFPRegs:$src))) and (set IntRegs:$dst (bitconvert (fp_lo DFPRegs:$src))) 2) Create a node similar to copytoreg that has...

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

.../ Node cannot be illegal if types are legal + break; + case ISD::BUILD_VECTOR: + case ISD::INSERT_VECTOR_ELT: + case ISD::EXTRACT_VECTOR_ELT: + case ISD::CONCAT_VECTORS: + case ISD::EXTRACT_SUBVECTOR: + case ISD::VECTOR_SHUFFLE: + case ISD::SCALAR_TO_VECTOR: + case ISD::BIT_CONVERT: + case ISD::LOAD: + case ISD::STORE: + // These are intentionally not handled here; the point of this is to + // eliminate illegal operations that could potentially be unrolled to + // illegal types. Leaving them around can also help optimization. + break; + case ISD:...