similar to: [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations

Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations"

2009 May 20
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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 > simplification.  There are still some issues with this patch, but does > the approach
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2012 Jul 30
2
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =
2012 Jul 30
2
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
v4i8 itself is a legal type, just not on the 'AND' operation. So there seems to be multiple problems here. 1) PromoteVectorOp doesn't handle the case where the types are not the same size, this occurs because #2 2) getTypeToPromoteTo doesn't actual check to see if the type it should promote to makes any sense. 3) PromoteVectorOp also doesn't handle the case where
2012 Jul 30
0
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah
2014 Feb 08
2
[LLVMdev] selecting ISD node - help
Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are
2012 Jul 30
0
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not
2016 Oct 29
1
Problems with Inline ASM expressions generated in the back end
Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry
2012 Jul 30
4
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken
2012 Jul 30
0
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the
2017 Jul 29
2
ISelDAGToDAG breaks node ordering
Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions
2008 Sep 12
3
[LLVMdev] Difficulty with reusing DAG nodes.
I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);
2017 Jul 31
0
ISelDAGToDAG breaks node ordering
On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >
2012 Jul 30
1
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
The comments in the code state it should do bitcast, op, then bitcast, not extend, op and truncate. "SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64." So following the same logic <4 x i8> bitcasts into a
2012 Nov 24
2
[LLVMdev] Fwd: Prevention register promotion at the isel codegen phase
Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I
2017 Dec 26
2
Canonical way to handle zero registers?
Thanks! That looks like a winning approach. I swear I grepped around for ISD::Constant but for some reason never found this code. I think maybe I was searching for ISD::Constant with setOperationAction, which in hindsight was narrowing down my search to just lowering, which is exactly what I didn't want! (I was looking for other approaches). I also tried looking in depth at PowerPC but it
2019 Jun 26
2
How to handle ISD::STORE when both operands are FrameIndex?
On Wed, Jun 26, 2019 at 12:38 PM Tim Northover <t.p.northover at gmail.com> wrote: > Hi Gleb, > > On Wed, 26 Jun 2019 at 07:28, Gleb Popov <6yearold at gmail.com> wrote: > > def StoreStackF : InstRI<2, (outs), (ins IntRegs:$reg, i32imm:$i), > > "storestackf $reg, [$i]", [(store_stack i32:$reg, > AddrFI:$i)]>; > > >
2012 Jul 27
4
[LLVMdev] Vector promotion broken for <2 x [i8|i16]>
Vector promotion which is new in LLVM 3.1 is broken for sub32 bit types. The problem is in the VectorLegalizer::PromoteVectorOp. The function getTypeToPromoteTo will return a <2 x i32> for a <2 x i8>, <2 x i16> or <4 x i8>. The problem is that there are no vectors of size 1 defined for i32 or i16. The attached patch fixes these issues. This can be reproduced by setting in