search for: i65

...to eliminate the loop; computing the exit value of > one of the loop variables uses the wide multiply. It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your input and got the attached file. I thought I could add "nuw nsw" to the arithmetic inside the loop to say that i65 is unnecessary, but that doesn't cause indvars to leave the arithmetic at i64. Is that a bug in indvars, or in SCEV, or is this just a natural limitation of SCEV? -------------- next part -------------- A non-text attachment was scrubbed... Name: fc_long.ll Type: application/octet-stream Size:...

Hi all, hope someone can help me out with this. Background Introduction I have a data set consisting of data collected from a questionnaire that I wish to validate. I have chosen to use confirmatory factor analysis to analyse this data set. Instrument The instrument consists of 11 subscales. There is a total of 68 items in the 11 subscales. Each item is scored on an integer scale between 1 to 4.

...use i8/i16/i32/i64 as a condition value. I also plan to experiment with promoting <4 x i1> to <4 x i32>. At this point I can't really say what needs to be done. Implementing this kind of promotion also requires adding legalization support for strange vector types such as <4 x i65>. -Nadav -----Original Message----- From: David A. Greene [mailto:greened at obbligato.org] Sent: Wednesday, March 09, 2011 21:59 To: Rotem, Nadav Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Vector select/compare support in LLVM "Rotem, Nadav" <nadav.rotem at intel.com&g...

...computing the exit value of >> one of the loop variables uses the wide multiply. > > It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your > input and got the attached file. I thought I could add "nuw nsw" to > the arithmetic inside the loop to say that i65 is unnecessary, but > that doesn't cause indvars to leave the arithmetic at i64. Is that a > bug in indvars, or in SCEV, or is this just a natural limitation of > SCEV? LLVM's ScalarEvolution's handling of non-linear recurrences has much room for improvement. The problem Mic...

...arget-specific thing. > I also plan to experiment with promoting <4 x i1> to <4 x i32>. At > this point I can't really say what needs to be done. Implementing > this kind of promotion also requires adding legalization support for > strange vector types such as <4 x i65>. How often do we see something like that? Baby steps, baby steps... :) -Dave

...ery: SELECT password FROM mailbox WHERE username = 'pablo.rodriguez at escuelasuperiordecoaching.com' Aug 31 08:39:45 socrates dovecot: auth(default): client out: OK^I1^Iuser=pablo.rodriguez at escuelasuperiordecoaching.com Aug 31 08:39:45 socrates dovecot: auth(default): master in: REQUEST^I65^I16796^I1 Aug 31 08:39:45 socrates dovecot: auth-worker(default): sql(pablo.rodriguez at escuelasuperiordecoaching.com,81.39.27.227): SELECT maildir, 1001 AS uid, 1001 AS gid FROM mailbox WHERE username = 'pablo.rodriguez at escuelasuperiordecoaching.com Aug 31 08:39:45 socrates dovecot: auth-w...

...computing the exit value of >> one of the loop variables uses the wide multiply. > > It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your > input and got the attached file. I thought I could add "nuw nsw" to > the arithmetic inside the loop to say that i65 is unnecessary, but > that doesn't cause indvars to leave the arithmetic at i64. Is that a > bug in indvars, or in SCEV, or is this just a natural limitation of > SCEV? LLVM's ScalarEvolution's handling of non-linear recurrences has much room for improvement. The problem Mic...

...yping inherent in LLVM. For example, I define one of the custom types in my language to i64, but this only makes sense as long as I can uniquely identify this type as i64 - that is I haven't overloaded i64 to mean anything else. Other types could be introduced as other bit-width integers (i65), structure types, etc. So it's possible, if not clean. Actually, looking over the list of optimizations on LLVM IR I'm having trouble finding more than a handful that explicitly rely on the storage type of all data. So it seems like a very valid use case to use LLVM for optimization...

...arget-specific thing. > I also plan to experiment with promoting <4 x i1> to <4 x i32>. At > this point I can't really say what needs to be done. Implementing > this kind of promotion also requires adding legalization support for > strange vector types such as <4 x i65>. How often do we see something like that? Baby steps, baby steps... :) -Dave --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of...

"Rotem, Nadav" <nadav.rotem at intel.com> writes: > I can think of two ways to represent masks in x86: sparse and > packed. In the sparse method, the masks are kept in <4 x 32bit> > registers, which are mapped to xmm registers. This is the ‘native’ way > of using masks. This argues for the sparse representation, I think. > _Sparse_ After my discussion with

...use i8/i16/i32/i64 as a condition value. I also plan to experiment with promoting <4 x i1> to <4 x i32>. At this point I can't really say what needs to be done. Implementing this kind of promotion also requires adding legalization support for strange vector types such as <4 x i65>. -Nadav -----Original Message----- From: David A. Greene [mailto:greened at obbligato.org] Sent: Wednesday, March 09, 2011 21:59 To: Rotem, Nadav Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Vector select/compare support in LLVM "Rotem, Nadav" <nadav.rotem at intel.com&g...

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The carry i was after was able to be obtained using t...

Hello, I started working on adding vector support for the SELECT and CMP instructions in the codegen (bugs: 3384, 1784, 2314).  Currently, the codegen scalarizes vector CMPs into multiple scalar CMPs.  It is easy to add similar scalarization support to the SELECT instruction.  However, using multiple scalar operations is slower than using vector operations. In LLVM, vector-compare operations

On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I have a test case(attached as fc_long.ll) that when run through the > optimizer produces 65bit integer math(fc_long-opt.ll). > > > > Now I understand that llvm can have any length integer, but I consider > turning a 64bit mul into multiple 65 bit instructions to be a ‘bad’ >

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

I was able to get the loop to increment from -999 to 0 using IR directly. That got rid of the cmpq. The carry i was after was able to be obtained using the intrinsic @llvm.uadd.with.overflow.i64, however there is no way to add with carry and have it realise that the resulting *carry out* cannot exceed 1. It actually writes the carry to a byte, and then uses logical operations on it, which slows

.../i16/i32/i64 as a condition value. > > I also plan to experiment with promoting<4 x i1> to<4 x i32>. At this point I can't really say what needs to be done. Implementing this kind of promotion also requires adding legalization support for strange vector types such as<4 x i65>. > > -Nadav > > > > -----Original Message----- > From: David A. Greene [mailto:greened at obbligato.org] > Sent: Wednesday, March 09, 2011 21:59 > To: Rotem, Nadav > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Vector select/compare support in LLVM > &...

I have a test case(attached as fc_long.ll) that when run through the optimizer produces 65bit integer math(fc_long-opt.ll). Now I understand that llvm can have any length integer, but I consider turning a 64bit mul into multiple 65 bit instructions to be a 'bad' optimization. This eventually expands to a 128bit multiply call(__multi3) which I have absolutely no interest in supporting.

...the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. > > Alistair > > On 13 Jun 2010, at 02:27, Bill Hart wrote: > >> I was able to get the loop to increment from -999 to 0 using IR >> directly. That got rid of the cmpq. >> >> The carry i was...

Alexandre Cossette wrote: > Hi all, > > I'm designing a programming language named C³ (or C3). I'm already using LLVM as a back-end for my prototype compiler and it's wonderful to use. Thanks for such a great system! > > I now have more ambitious goals and I would like to use the LLVM IR as my internal C³ IR. Absolutely not. In short, LLVM is its own language. You