Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] About writing an alias analysis pass for LLVM 3.1"
2012 Sep 10
0
[LLVMdev] About writing an alias analysis pass for LLVM 3.1
Hi,
Does your pass use multiple inheritance? Sounds like your problem is
that you need to define getAdjustedAnalysisPointer, see:
http://llvm.org/docs/doxygen/html/classllvm_1_1Pass.html#a03d3a81b1c46aff7c38ef3a6750ba225
An example implementation (very likely exactly what you want) is in
LibCallAliasAnalysis:
http://llvm.org/docs/doxygen/html/LibCallAliasAnalysis_8h_source.html#l00060
Hope
2015 Apr 30
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
I don't think we should make flush virtual. Why do you need to do it?
Can't you set up the base class to write to use the tail of the memory
region as the buffer?
On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote:
> Hi,
>
> Is this what you're thinking about?
> The code is not tested yet, I'd like to know if the overall direction and
>
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Could you dig into why:
+ raw_ostream &write(unsigned char C) override {
+ grow(1);
+ *OutBufCur++ = C;
+ return *this;
+ }
Is 3 times as fast as raw_svector_ostream? I don't see a good reason why
that should be any faster than:
raw_ostream &operator<<(char C) {
if (OutBufCur >= OutBufEnd)
return write(C);
*OutBufCur++ = C;
return *this;
}
2015 Apr 20
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Sean, thanks for reminding this, Alp did commit a class derived from
raw_svector_ostream conatining an internal SmallString he called
small_string_ostream.
The commit was reverted after a day due to a disagreement about the commit
approval and apparently abandoned.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html
2015 May 02
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
+update diff
2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> I outlined (is that the right
> word?) raw_char_ostream::grow, raw_char_ostream::write (both) into
> raw_ostream.cpp with less than 10% difference in performance.
>
> Profiling reveals that the real culprit is the code line
>
> OS.reserve(OS.size() + 64);
>
> called from
2015 Apr 19
6
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
A very common code pattern in LLVM is
SmallString<128> S;
raw_svector_ostream OS(S);
OS<< ...
Use OS.str()
While raw_svector_ostream is smart to share the text buffer itself, it's
inefficient keeping two sets of pointers to the same buffer:
In SmallString: void *BeginX, *EndX, *CapacityX
In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur
Moreover, at runtime the
2016 Mar 22
2
Passing llvm option -mem2reg to clang
I have used the following command for my pass (without -mem2reg):
clang -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c
For mem2reg, I tried the following:
clang -mllvm -mem2reg -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c
On Mon, Mar 21, 2016 at 9:26 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>> On Mar 21, 2016, at 6:23 PM, Syed Rafiul Hussain
2016 Mar 22
1
Passing llvm option -mem2reg to clang
Unless mem2reg does something other than my understanding of it, I can't
see why any pass would "require" that... It is not guaranteed to do
anything to any particular piece of code, so relying on it seems very
unreliable, I would think.
--
Mats
On 22 March 2016 at 04:32, Kevin Hu via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Hi,
>
> > Is there any way that
2015 Aug 12
2
SmallString + raw_svector_ostream combination should be more efficient
+llvm-dev at lists.llvm.org
The impact should be small as all the other streamers usually write
directly to the memory buffer and only when out of buffer they call write().
OTOH, raw_svector_ostream (without a buffer) goes though write for every
character or block it writes. It can work without virtual write() by
overriding the existing virtual write_impl() but this is a slower code path
for
2015 May 22
2
[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient
Here's a performance testcase for the raw_svector_ostream patch. On my
WIndows x64 machine it runs in 1010ms with the current code and in 440ms
with the patch applies. Is this OK to commit?
2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>:
> Following a hint from Duncan in http://llvm.org/pr23395, here is a
> revised patch. Rather then introduce the
2005 Jan 26
2
postscript() and levelplot() in a for loop
Hi,
I like to produce a series of levelplot graphs in postscript file, so I put
the trunk of codes including postscript() and levelplot() in a for loop. The
codes work fine outside the loop, but only produce empty .ps file when being
put within the loop. Is it a problem associated with postscript() or
levelplot()? How to get around the problem? Many thanks!
Yan
[[alternative HTML
2015 Jun 17
8
[Bug 11338] New: Rsync Crash - Segmentation fault
https://bugzilla.samba.org/show_bug.cgi?id=11338
Bug ID: 11338
Summary: Rsync Crash - Segmentation fault
Product: rsync
Version: 3.1.1
Hardware: x64
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: core
Assignee: wayned at samba.org
Reporter:
2016 Dec 07
2
Race condition in raw_ostream
> On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <viacheslav.nikolaev at gmail.com> wrote:
>
> > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write().
>
> Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted?
> I cannot see if that is so. And I really saw it didn't
2016 Dec 07
2
Race condition in raw_ostream
This code from raw_ostream.h is really racy:
raw_ostream &operator<<(StringRef Str) {
// Inline fast path, particularly for strings with a known length.
size_t Size = Str.size();
// Make sure we can use the fast path.
if (Size > (size_t)(OutBufEnd - OutBufCur))
return write(Str.data(), Size);
if (Size) {
memcpy(OutBufCur, Str.data(), Size);
2015 Aug 06
2
LibCallAliasAnalysis class instantiation parameter
Hello,
[sorry for the duplicate post, attempting to fix the formatting of the previous post]
Can anybody tell me the intent of the LibCallAliasAnalysis class? I see that to instantiate it, it requires a class derived from the pure virtual class LibCallInfo, but I cannot find any classes in the source tree that derive from LibCallInfo. Is this derived class intended to be supplied from a compiler
2016 Dec 07
3
Race condition in raw_ostream
On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > This code from raw_ostream.h is really racy:
> >
> > raw_ostream &operator<<(StringRef Str) {
> > // Inline fast path,
2015 Aug 13
2
SmallString + raw_svector_ostream combination should be more efficient
r244870 (with the change you requested), thanks!
I initially placed the virtual function in header since they were
one-liners.
The coding standards say that an anchor() function should be supplied,
which was indeed missing. Other than required anchor function, why should
the virtual functions go in the .cpp?
Should I move the empty raw_svector_ostream destructor to the .cpp file too
as well?
2017 Nov 29
4
CodeExtractor buggy?
Hi All,
I’m currently working on a simple task which needs to transform loops into tail-recursive functions. I found the CodeExtractor class a handy helper to use, but later encountered a problem.
Consider the following CU
struct S { int a, b; };
int foo(struct S *s, unsigned n) {
struct S *next = s;
unsigned i;
for (i = 0; i < n; ++i) {
if (!s[i].a)
2008 May 17
3
[LLVMdev] VS build is broken again
attached is the diff of vcprojs that need to be changed to fix the VS
build as of revision: 51224.
I don't know if this catches all the missing bits, but this does build
all the way through.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: msvs.patch
URL:
2008 May 18
0
[LLVMdev] VS build is broken again
Hi Dmitri,
For what version of VS did you update the project files?
Ted
On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote:
> attached is the diff of vcprojs that need to be changed to fix the VS
> build as of revision: 51224.
>
> I don't know if this catches all the missing bits, but this does build
> all the way through.
>
>
> Index: win32/Analysis/Analysis.vcproj