similar to: [LLVMdev] bits in a pointer

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] bits in a pointer"

2012 May 21
3
[LLVMdev] APInt::sdivrem error?
I wrote the following bit of code static APInt FloorOfQuotient(APInt a, APInt b) { unsigned bits = a.getBitWidth(); APInt q(bits, 1), r(bits, 1); APInt::sdivrem(a, b, q, r); * errs() << "sdivrem(" << a << ", " << b << ") = (" << q << ", " << r << ")\n"; * if (r == 0) return q; else {
2012 May 21
0
[LLVMdev] APInt::sdivrem error?
OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =
2007 Oct 07
5
[LLVMdev] The definition of getTypeSize
Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking
2007 Oct 08
0
[LLVMdev] The definition of getTypeSize
On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > >
2012 Apr 19
0
[LLVMdev] SIV tests in LoopDependence Analysis, Sanjoy's patch
Hi Sanjoy, Here's a version of Banerjee and Wolfe's Exact SIV test: https://sites.google.com/site/parallelizationforllvm/weak-siv-test It assumes you've already filtered out the easy cases handled by ZIV, strong SIV, etc. I'm not confident about my uses of APInt. If you have any comments, I'd love to hear them. Thanks, Preston On Thu, Apr 12, 2012 at 5:14 AM, Sanjoy Das
2012 Apr 20
2
[LLVMdev] SIV tests in LoopDependence Analysis, Sanjoy's patch
On Wed, 18 Apr 2012 18:16:47 -0700 Preston Briggs <preston.briggs at gmail.com> wrote: > Hi Sanjoy, > > Here's a version of Banerjee and Wolfe's Exact SIV test: > https://sites.google.com/site/parallelizationforllvm/weak-siv-test > It assumes you've already filtered out the easy cases handled by ZIV, > strong SIV, etc. > > I'm not confident about my
2007 Oct 08
3
[LLVMdev] The definition of getTypeSize
Hi Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined.
2012 Nov 13
2
[LLVMdev] loop carried dependence analysis?
Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On
2012 Nov 13
2
[LLVMdev] loop carried dependence analysis?
Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.
2012 Oct 03
3
[LLVMdev] Does LLVM optimize recursive call?
On Wed, Oct 3, 2012 at 10:15 AM, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote: > Preston Briggs <preston.briggs at gmail.com> writes: >> Think about costs asymptotically; that's what matters. Calls and >> returns require constant time, just like addition and multiplication. > > Constant time, but not necessarily constant memory. > > Deep recursion
2012 Nov 13
0
[LLVMdev] loop carried dependence analysis?
Preston, thanks for the explanation and patch. Now it's printing the direction and distance values. On Tue, Nov 13, 2012 at 12:22 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Erkan, you're right. Sorry about that. > Attached is the most recent version. > > Preston > > > > Hi Preston, >> I am trying to use DA as well. I used your example
2012 Nov 02
2
[LLVMdev] DependenceAnalysis and PR14241
On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November
2018 Sep 11
2
linear-scan RA
The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.
2018 Sep 11
2
linear-scan RA
Yes, I quite liked the things I've read about the PBQP allocator. Given what the hardware folks have to go through to get 1% improvements in scalar code, spending 20% (or whatever) compile time (under control of a flag) seems like nothing. And falling back on "average code" is a little disingenuous. People looking for performance don't care about average code; they care about
2012 Nov 14
0
[LLVMdev] loop carried dependence analysis?
On 13.11.2012, at 10:46, erkan diken <erkandiken at gmail.com> wrote: Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to
2012 Nov 02
2
[LLVMdev] DependenceAnalysis and PR14241
On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked
2012 Jan 26
0
[LLVMdev] dense maps
My problem was that the constructor for DenseMap has an undocumented constraint. explicit DenseMap(unsigned NumInitBuckets = 0) { init(NumInitBuckets); } if given an explicit argument, requires that the argument be a power of 2. It's checked by an assert in init(), but for some reason my code didn't trip the assertion. Is there a special way I must make to enable asserts? Thanks,
2018 Sep 11
2
linear-scan RA
> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2
2018 Sep 11
2
linear-scan RA
Hi, Using Chaitin's approach, removing a copy via coalescing could expose more opportunities for coalescing. So he would iteratively rebuild the interference graph and check for more opportunities. Chaitin was also careful to make sure that the source and destination of a copy didn't interfere unnecessarily (because of the copy alone); that is, his approach to interference was very
2012 Nov 02
0
[LLVMdev] DependenceAnalysis and PR14241
Here's the current code (abstracted a bit) const Instruction *Src, const Instruction *Dst, // make sure they are loads and stores, then const Value *SrcPtr = getPointerOperand(Src); // hides a little casting, then Src->getPointerOperand const Value *DstPtr = getPointerOperand(Dst); // ditto // see how underlying objects alias, then const GEPOperator *SrcGEP =