similar to: [LLVMdev] Instruction selection of intrinsics

Hi, The target supports indexing by register or immediate. Multiplications are not supported by any load / store instructions. Would it be possible to make LSR aware of this? Thanks, Jonas Paulsson -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, December 01, 2012 5:59 AM To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LSR pass

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 1:40:24 PM > Subject: [LLVMdev] LSR pass > > > > > > Hi, > > > > I would like some help regarding the LSR pass. It seems that it likes > to duplicate address calculations as in the

Hi, On 03/30/2016 11:15 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On my out-of-tree target I have an intrinsic >> >> def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], >> [llvm_i16_ty, llvm_i16_ty], >>

Hi, all right, no fixed point type in LLVM :-( May I ask then, what could one expect from various optimizations when using intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? Are you saying it is feasible to add intrinsics and some extra optimizers for these, then? Best regards, Jonas > Subject: Re: [LLVMdev] fixed point types > From: clattner at apple.com >

> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my out-of-tree target I have an intrinsic > > def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], > [llvm_i16_ty, llvm_i16_ty], > [IntrNoMem]>; > > that I want to translate to the

Hi, On my out-of-tree target I have an intrinsic def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], [llvm_i16_ty, llvm_i16_ty], [IntrNoMem]>; that I want to translate to the following instruction during instruction selection: def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins

Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a

<retitling to be useful> LLVM shouldn't have a fixed point type class. You should just use standard integer types. Supporting fixed point and saturation should by done by adding new operations to llvm IR. If you're interested in this, I'd suggest starting by implementing these as intrinsics. If it makes sense over time we can change them to primitive instructions if there is

> On Mar 30, 2016, at 11:58, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > > > On 03/30/2016 11:51 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >>> >>> Hi, >>> >>> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>>>

Hi, I need to pass pointer arguments and integer arguments in different register classes, but fail to do this. I am surprised to see no pointer type in the initial DAG and both these programs get arguments of i16: int fun(int a, int b) { return a+b;} int funp(int *a, int *b) { return *a+*b;} The arguments get the same MVT::i16, and as well - surprisingly - the same ArgFlags.Flags for both

> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > Hi, > > On 03/30/2016 11:38 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>> <mailto:mikael.holmen at ericsson.com>> wrote: >>> >>> i16 (divm16_pseudo …) >>>

On 03/30/2016 11:51 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >> >> Hi, >> >> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>> >>>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>>> <mailto:mikael.holmen at

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

You probably meant to send this to LLVMdev as well. Begin forwarded message: Date: Mon, 29 Nov 2010 08:26:03 +0100 From: Jonas Paulsson <jnspaulsson at hotmail.com> To: <edwintorok at gmail.com> Subject: RE: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41 Yes, the new type is simply a static object managed by Type and LLVMContext. This is only referred to by Values of fixed point type.

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

Hi, thanks a lot for the answer. By mem, I meant optimizations that involves load/store intrinsics, eg llvm.fixPload(). What would the consequences of this be? I ask then, is there any interest at all in the LLVM community for fixed point support in the future? Are there even any local successful projects that you know of? Did you mean that fixed point support in terms of intrinsics and code

Hi Eli, Thanks for your response. Actually, I look a lot at the ARM and THUMB1 backend implementations, and this certainly help. My architecture also have specific instructions for SP-relative accesses in a similar way than the Thumb1. During frame lowering, specific machine instructions are emitted so there’s no issue there. Also during ISelDagToDag I am able to select the right instructions.

> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > i16 (divm16_pseudo …) > > stuff? > > I've tried > (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) > and > ((i16, i16) (divm16_pseudo i16:$src1, i16:$src2) > and a few other variants without managing to get it through. > > Thanks again, > Mikael Are you

Hi, I have come across a major regression resulting after SLP vectorization (+18% on SystemZ, just for enabling SLP). This all relates to one particular very hot loop. Scalar code: %conv252 = zext i16 %110 to i64 %conv254 = zext i16 %111 to i64 %sub255 = sub nsw i64 %conv252, %conv254 ... repeated SLP output: %101 = zext <16 x i16> %100 to <16 x i64> %104 = zext

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16)