Displaying 20 results from an estimated 130 matches similar to: "[LLVMdev] Issues with DependenceAnalysis"
2013 Mar 18
2
[LLVMdev] UNREACHABLE executed! error while trying to generate PTX
I am trying to generate PTX code for 'nbody' sample program's kernel
(nbody_kernel.cu) using clang/LLVM version 3.2. The nbody CUDA program is
available in Nvidia's SDK.
I am referring to https://github.com/jholewinski/llvm-ptx-samples project.
Following are my commands,
clang++ -O4 -S -I/usr/local/cuda/include -emit-llvm -target nvptx64
nbody_kernel.cu -o nbody_kernel.ll
2013 Mar 18
0
[LLVMdev] UNREACHABLE executed! error while trying to generate PTX
I noticed you're using cuda_runtime.h in the source file. Where are you
getting this file? From the CUDA toolkit?
Since the error is in the back-end, can you just post the .ll or .bc file
you are trying to compile?
On Mon, Mar 18, 2013 at 12:42 AM, upit <uday_pitambare at yahoo.com> wrote:
> I am trying to generate PTX code for 'nbody' sample program's kernel
>
2012 Nov 02
0
[LLVMdev] DependenceAnalysis and PR14241
Hi Chandler,
Thanks for writing.
Could you give me some C (or C++) for an illustrative example.
I think I understand your concern, but I'd like to be sure.
Thanks,
Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121102/88c02212/attachment.html>
2012 Nov 02
2
[LLVMdev] DependenceAnalysis and PR14241
On 02.11.2012, at 15:53, Preston Briggs <preston.briggs at gmail.com> wrote:
> Hi Chandler,
>
> Thanks for writing.
> Could you give me some C (or C++) for an illustrative example.
> I think I understand your concern, but I'd like to be sure.
Hi Preston,
The bug report at http://llvm.org/bugs/show_bug.cgi?id=14241 has more details, including a C++ test case.
- Ben
2012 Nov 02
0
[LLVMdev] DependenceAnalysis and PR14241
I see, thanks Ben.
So yes, I certainly misunderstood (more likely "misunderstand") how things
work.
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
2012 Nov 02
0
[LLVMdev] DependenceAnalysis and PR14241
----- 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 2, 2012 12:56:53 PM
> Subject: Re: [LLVMdev]
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
2017 Jun 21
2
A bug in DependenceAnalysis?
Hello llvm-dev,
I'm running a pass that uses the result of
llvm::DependenceAnalysisWrapperPass to compute the dependencies between all
instructions of a loop. I have the following two examples of code I wish to
analyse:
example A:
```
void move_one(int *A, unsigned n) {
for (unsigned i = 0; i < n-1; ++i) {
A[i] = A[i + 1];
}
}
```
and example B:
```
void move_one_alt(int *A,
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 =
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
2013 May 23
1
[LLVMdev] Polyhedron 2005 results for dragonegg 3.3svn
On Thu, May 23, 2013 at 03:40:00PM +0200, Duncan Sands wrote:
> Hi Jack,
>
> On 23/05/13 15:37, Jack Howarth wrote:
>> Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current
>> FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is
2020 May 22
2
Creating a copy Pass of DependenceAnalysis
Hi,
I want to create a copy of DependenceAnalysis downstream.
At first I tried the HelloWorld tutorial. But then I figured, maybe I
should move on
to create my pass by mimicking some other pass in LLVM.
So, I tried copying DependenceAnalysis itself [1]
Although after a lot of time of trying it compiled, I'm pretty sure I have
done it
completely in the wrong way. What is more, I can't
2017 Jun 21
2
A bug in DependenceAnalysis?
Hi Philip,
Thanks for checking!
I'm running my own Foo pass that registers DependenceAnalysisWrapperPass as
a prerequisite and then I run it like so:
opt -load libfoo.so -foo example.bc
This is LLVM 3.9.
Cheers,
- Stan
On Wed, Jun 21, 2017 at 5:40 PM, Philip Pfaffe <philip.pfaffe at gmail.com>
wrote:
> Hi Stan,
>
> in both cases I get a consistent anti result. Can you
2019 May 24
2
Delinearization validity checks in DependenceAnalysis
[CC bollu, mferguson, shil]
Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour <
bmahjour at ca.ibm.com>:
> Thanks David and Michael for the clarification.
>
> I think I understand the rational behind those checks in delinearization
> now.
>
> > Some other languages have stronger guarantees about their array
> dimensions accesses being in range. But this being
2013 Dec 27
3
[LLVMdev] Using DependenceAnalysis::depends
Hi
I want to analyse the memory dependencies which exist in a loop at an intra
iteration as well as inter iteration (loop carried dependencies). I looked
at the DependenceAnalysis implementation which returns a lot of the
information I require (based on a prior AliasAnalysis pass), however I need
to pass the Src and Dst instructions in program order.
I was wondering how I can collect all the
2012 Nov 02
3
[LLVMdev] DependenceAnalysis and PR14241
Hey Preston,
I wanted to let you know that we found a really serious problem with
DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in
assumption that the base pointer of the GEPs it inspects are loop
invariant. It appears to only do analysis on the subscripts.
This is especially important for LLVM because C++ code (compiled
through Clang) very frequently expresses loops as
2013 Mar 05
0
[LLVMdev] Issue with PrintStackTrace (probably a bug?)
Hello there,
I'm doing some modifications on an ll file generated by llvm just to learn some more about the llvm text intermediate language. However, I'm having some issues while using lli to execute the modified ll, and, although sometimes the program just freezes, the following message is being printed most of the times:
0 libLLVM-3.3svn.dylib 0x000000010fdd813e
2017 Jun 22
2
A bug in DependenceAnalysis?
Hi Philip,
I forgot to mention that I was ignoring loop-independent dependences. If I
don't I get an inconsistent, ordered, anti, loop-independent dependence and
an inconsistent, ordered, flow, loop-carried dependence for example A. At
the same time I get just a consistent, ordered, anti, loop-independent
dependence for example B.
Here's the .ll code for example A:
*; Function Attrs:
2013 Dec 27
4
[LLVMdev] Using DependenceAnalysis::depends
Hi Preston,
Thank you for the prompt response.
You can use DependenceAnalysis to get the info you want by expensively
> testing all pairs of memory references.
Isn't all pairs testing incorrect in the sense that a pair may only exist
for a certain path? Consider the following example.
A[i] = 42; // S1
if( condition ) // C1
{
A[i] = 20; // S2
}
B[i] = A[i];
2019 Feb 07
2
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
Hi,
Following is a proposal to improve location coverage for Function parameters in LLVM. The patches for review will be posted soon.
RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters
Ananthakrishna Sowda(Cisco), asowda at cisco.com
Nikola Prica (RT-RK/Cisco), nprica at rtrk.com
Djordje Todorovic(RT-RK/Cisco), djtodorovic at rtrk.com
Ivan Baev