Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] range-analysis in Function Pass on Eclipse with CMake"
2013 Sep 24
0
[LLVMdev] range-analysis in Function Pass on Eclipse with CMake
dw <dw.dev.mailing at gmail.com> writes:
[snip]
> Everything compiles fine, but loading the pass in LLVM gives me the
> following error:
>
>> /opt/llvm/bin/opt: symbol lookup error: ./build/lib/RangeAnalysis.so: undefined symbol: _ZN4llvm13ConstantRangeC1ENS_5APIntES1_
>> error: unable to interface with target machine
>
> I use LLVM 3.4svn on Ubuntu x64.
>
2011 Feb 25
0
[LLVMdev] Question about Value Range Propagation
Hi, Andrey,
sorry for the delay: I made a page with the code available for download:
http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html
Feel free to get it, and if you need some help, I will be happy to tell
you how to set the analysis up, in case the explanation in the page is not
good.
I also have a report describing the implementation here: (
2011 Feb 25
1
[LLVMdev] Question about Value Range Propagation
Can't read your paper because the permission is not set.
Chuck
On 2/25/2011 12:16 PM, Douglas do Couto Teixeira wrote:
> Hi, Andrey,
>
> sorry for the delay: I made a page with the code available for
> download:
> http://homepages.dcc.ufmg.br/~douglas/projects/RangeAnalysis/RangeAnalysis.html
>
2011 Mar 23
0
[LLVMdev] Range Analysis GSoC 2011 Proposal
Dear Douglas,
Comments below.
On 3/23/11 8:06 AM, Douglas do Couto Teixeira wrote:
> Dear LLVM community,
>
> I would like to contribute to LLVM in the Google Summer of Code
> project. My proposal is listed below. Please let me know your comments.
>
>
> Adding Range Analysis to LLVM
>
>
>
> Abstract
>
> The objective of this work is patch our
2011 Feb 22
6
[LLVMdev] Question about Value Range Propagation
Hi Douglas,
On 21.02.2011 20:27, Douglas do Couto Teixeira wrote:
> My work is not part of the LLVM mainline yet. But I would be happy to
> contribute with the code of my range analysis implementation if it can help
> you in something else.
We were thinking of adding VRP to LLVM too, though we were mostly
interested in Patterson's approach (i.e. not connected with SSI form). It
2013 Jul 16
0
[LLVMdev] eclipse and gdb
Hi Reed,
I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
Xcode works fine as well, I started to use Xcode exclusively when I switched to OS X.
The key to make this work is to
2011 Mar 23
3
[LLVMdev] Range Analysis GSoC 2011 Proposal
Dear LLVM community,
I would like to contribute to LLVM in the Google Summer of Code project. My
proposal is listed below. Please let me know your comments.
Adding Range Analysis to LLVM
Abstract
The objective of this work is patch our implementation of range analysis
into LLVM. I have a running implementation of range analysis in LLVM, but it
is not currently part of the main distribution. I
2009 Jul 05
0
[LLVMdev] LLVM and Eclipse
Hi Oscar,
On Thu, Jul 2, 2009 at 2:59 PM, Óscar Fuentes<ofv at wanadoo.es> wrote:
>> It might be worth to put an Eclipse CDT project file with relative
>> paths to the header files in the LLVM SVN repository to make it easier
>> for people to use Eclipse in the future (my project files currently
>> contain absolute paths, so they're probably not useful to other
2013 Jul 16
3
[LLVMdev] eclipse and gdb
On 07/16/2013 05:21 AM, Tilmann Scheller wrote:
> Hi Reed,
>
> I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
>
> Xcode works fine as well, I started to use Xcode
2013 Jul 17
2
[LLVMdev] eclipse and gdb
On 07/16/2013 05:21 AM, Tilmann Scheller wrote:
> Hi Reed,
>
> I’ve used Eclipse for a long time to do LLVM development on Linux (both for code navigation/editing and debugging), any recent Linux distribution and version of Eclipse should be fine (even older versions should be good enough as this has been working for many years).
>
> Xcode works fine as well, I started to use Xcode
2016 Jun 10
2
Early CSE clobbering llvm.assume
Yeah, that change is completely unrelated, that is about correctness, this
is about optimization.
I'm working on a proposal to just fix assume at some point to deal with the
former issue.
The problem with this testcase is that all the ways assume is propagate
expect the variable in the assume to later be used.
<This is the main way assume constants are propagated>
bool
2012 Apr 29
2
[LLVMdev] ConstantRange in PR1255
Hmmm... why?
Duncan Sands wrote:
> Hi Stepan,
>
>> Well... each case is represented as pair<BB, vector<Range> >. Right?
>
> after thinking about this some more I think you are right to not use
> ConstantRange, and instead to build your own set abstraction.
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing
2011 Jun 21
2
[LLVMdev] ConstantRange::sub
Hi,
I have a question about ConstantRange::sub(const ConstantRange &Other) at lib/Support/ConstantRange.cpp:524. The code computes the new bounds as follows.
APInt NewLower = getLower() - Other.getLower();
APInt NewUpper = getUpper() - Other.getUpper() + 1;
Could someone explain this to me? I was expecting something like
APInt NewLower = getLower() - Other.getUpper() + 1;
APInt
2019 Dec 01
4
ConstantRange modelling precision?
Hello.
This question has come up in https://reviews.llvm.org/D70043
There, i'm teaching ConstantRange how no-wrap flags affect
the range of `mul` instruction, with end goal of exploiting
this in LVI/CVP.
There are certain combinations of ranges and no-wrap flags
that result in always-overflowing `mul`. For example,
`mul nuw nsw i4 [2,0), [4,0)` always overflows:
2011 Jun 22
2
[LLVMdev] ConstantRange::sub
Sure. I will submit a patch.
BTW, what's the difference between the bounds I was expecting
APInt NewLower = getLower() - Other.getUpper() + 1;
APInt NewUpper = getUpper() - Other.getLower();
and the two you mentioned
NewLower = Lower - (Upper-1)
NewUpper = (Upper-1) - Lower + 1
They look equivalent to me. Did I miss anything? Thanks.
- xi
On Jun 22, 2011, at 2:39 PM, Nick Lewycky
2012 Apr 26
2
[LLVMdev] ConstantRange in PR1255
Hi, Duncan.
unionWith result is differs from set union, since it produces single set
always while set operations may produce two sets.
E.g.:
For ranges
[1, 5) and [10,15)
unionWith produces [1,15), while set union should just keep these sets
without changing, probably with indication that sets are not
intersected. Implementation of set union is simple though.
The "symmetric
2017 Jul 24
2
LazyValueInfo vs ScalarEvolution
On Mon, Jul 24, 2017 at 2:29 PM, John Regehr via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 7/24/17 3:16 PM, Hongbin Zheng via llvm-dev wrote:
>
>> Thanks, maybe we could use ScalarEvolution in LazyValueInfo if it is
>> available?
>>
>
> This should be fairly easy to try, if you want to propose a patch and run
> some experiments. The question is
2016 Jun 10
3
Early CSE clobbering llvm.assume
Maybe. It may not fix it directly because you never use %1 or %2 again.
I haven't looked to see how good the lookup is.
On Fri, Jun 10, 2016, 3:45 PM Josh Klontz <josh.klontz at gmail.com> wrote:
> Thanks Daniel, with that knowledge I think I can at least work around the
> issue in my frontend.
>
> Ignoring GVN for a second though, and just looking at Early CSE, it seems
2012 Apr 29
0
[LLVMdev] ConstantRange in PR1255
Hi Stepan,
> Hmmm... why?
because you basically want pairs (set, destination) where set could be a
arbitrary set of integers. As in practice these sets are a union of a
small number of intervals, the set abstraction should efficiently represent
unions of intervals, but that's more of an optimization than anything else.
Probably for the needs of switch lowering you will need to expose the
2012 Apr 26
3
[LLVMdev] ConstantRange in PR1255
Well... each case is represented as pair<BB, vector<Range> >. Right?
We need "union" for optimal case building. And we need support "difference" if we decided that some ranges or numbers in case will never used (in some optimization passes it happens sometimes).
-Stepan
26.04.2012, 15:18, "Duncan Sands" <baldrick at free.fr>:
> Hi Stepan,
>