Displaying 20 results from an estimated 10000 matches similar to: "LTO on libraries"
2015 Dec 05
2
LTO on libraries
Thanks for the response.
To clarify in your suggestion, llvm-link will combine the modules but not run the optimization pass, that is still delayed until the final binary is built, correct?
My use case is apply LTO to roughly program subsets; sacrificing effectiveness to avoid scaling problems and to allow the artifacts to be reused like archives and cached like .o’s.
I need to trigger the
2015 Jan 03
4
[LLVMdev] LTO v. opt
Hi,
I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have also built the 3.6 LLVM binaries (from a few month old local branch).
The default version of “ld” from Apple supports an option “-save-temps” which I believe saves bitcode both before and after the
2015 Jan 05
2
[LLVMdev] LTO v. opt
On Jan 3, 2015, at 11:52 PM, Bill Wendling <isanbard at gmail.com> wrote:
> On Jan 2, 2015, at 8:32 PM, David Callahan <dcallahan at fb.com> wrote:
>
>> Hi,
>>
>> I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have
2015 Jan 05
2
[LLVMdev] LTO v. opt
Thanks to you both.
On my Linux (centos6) system, I have reproduce a variant of the bug and learned about
-plugin-opt=-debug-pass=Arguments
which I infer from comments is intended to built arguments to “opt” however I found that some of the arguments don’t seem to be quite correct. I assume this just minor bit rot.
bin/opt -o pass1.bc -datalayout -notti -basictti -x86tti -targetlibinfo
2015 Feb 04
2
[LLVMdev] LTO regression test Bug 17623
Hello,
I have a fix for Bug17623 (http://llvm.org/bugs/show_bug.cgi?id=17623) but I am not sure how best to install a regression test. The commands I use to run the test are (approximately)
$LLVM/clang -flto -O2 -o BUG.o -c BUG.c
$LLVM/llvm-lto -exported-symbol=main -o lto.o BUG.o
$LLVM/clang -o bug lto.o
./bug
Where the failing behavior is to seg fault and corrected behavior is to run to
2019 Jan 09
2
distributed thinlto usage
Fails with gold too:
Library-native.o:Library.cpp:regway: error: undefined reference to 'vtable for regwayobj'
/home/dcallahan/fbsource/fbcode/third-party-buck/platform007/tools/binutils/bin/gold/ld: the vtable symbol may be undefined because the class is missing its key function
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
From: Teresa Johnson
2019 Jan 09
2
distributed thinlto usage
Thanks Teresa
Yes it is astar, happen to send a tar of the sources but they are just copies from the spec distribution
The ld command is:
GNU ld (GNU Binutils) 2.29.1
Thanks for the guidance on path names. The prefix-replace just effects the string written to the object files right? So we could post-process that file with other tools as well, correct?
Thanks again
--david
From: Teresa Johnson
2016 Jan 30
3
DCE in the presence of control flow.
I had assumed you would treat phi nodes differently from other operations in that they don’t need to keep the block alive just to retain the data flow facts but it would be simplest to do that.
Thanks Daniel
From: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>>
Date: Friday, January 29, 2016 at 10:26 PM
To: David Callahan <dcallahan at
2016 Jan 30
4
DCE in the presence of control flow.
I think you can also avoid the RDF computation using a more directed form of control dependence testing such as described in
Keshav Pingali and Gianfranco Bilardi. 1997. Optimal control dependence computation and the Roman chariots problem. ACM Trans. Program. Lang. Syst. 19, 3 (May 1997), 462-491. DOI=http://dx.doi.org/10.1145/256167.256217
However one challenge seems to be fixing the SSA graph
2016 Aug 25
4
CFLAA
(and sys::cas_flag that STATISTIC uses is a uint32 ...)
On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> Okay, dumb question:
> Are you really getting negative numbers in the second column?
>
> 526,766 -136 mem2reg # PHI nodes inserted
>
> http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html
>
2016 Jan 30
0
DCE in the presence of control flow.
In practice, APT is not faster to build than rdf.
The df calculator we use is linear time and quite fast.
Updating is also pretty trivial since it's only deletes of dead and
unreachable code. So anything it reached can be replaced with undef in
most cases.
Cd-dce is not slower in GCC than dce
On Fri, Jan 29, 2016, 8:31 PM David Callahan <dcallahan at fb.com> wrote:
> I think you
2016 Jan 30
0
DCE in the presence of control flow.
Maybe I was too quick here. Does gcc record the incoming edge to a phi? If so, won’t those change when you delete blocks in a non-trivial manner? How are those updated?
From: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>
Date: Saturday, January 30, 2016 at 7:02 AM
To: Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>>, Hal Finkel
2015 Jan 30
1
[LLVMdev] LNT install
Hi David,
That's weird, I have setup LNT in multiple different distros and have
never seen this. Looks like no one ever tested on the system you're
running. Can you share a bit more of your environment?
Also, you can check the setup.py to see if it does any stripping of
package names, which could go wrong in the wrong environment.
cheers,
--renato
On 29 January 2015 at 20:13, David
2016 Jan 29
3
DCE in the presence of control flow.
On Thu, Jan 28, 2016 at 10:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> ------------------------------
>
> *From: *"David Callahan via llvm-dev" <llvm-dev at lists.llvm.org>
> *To: *"Daniel Berlin" <dberlin at dberlin.org>, "LLVM Dev Mailing list" <
> llvm-dev at lists.llvm.org>
> *Sent: *Thursday, January 28, 2016
2015 Jan 29
2
[LLVMdev] LNT install
I followed the lnt quickstart <http://llvm.org/docs/lnt/quickstart.html> directions but got this diagnostic when doing the setup:
bash-3.2$ ~/mysandbox/bin/python ~/lnt/setup.py develop
/Users/dcallahan/mysandbox/lib/python2.7/site-packages/setuptools/dist.py:284: UserWarning: The version spec\
ified requires normalization, consider using '0.4.1.dev0' instead of
2016 Apr 04
2
RFC: New aggressive dead code elimination pass
On Mon, Apr 4, 2016 at 11:49 AM, David Callahan <dcallahan at fb.com> wrote:
>
> I may have not correctly used the IDFCalculator. I passed in the
> PostDominator tree and then changed the loop over successor blocks to also
> be able to iterate over predecessors. I did not see anything in the
> interface that would let that happen but perhaps I don’t understand the API
> so
2016 Aug 25
2
CFLAA
(Adding "LLVM Dev")
My variant is up as https://reviews.llvm.org/D23876
-david
From: George Burgess IV <george.burgess.iv at gmail.com<mailto:george.burgess.iv at gmail.com>>
Date: Wednesday, August 24, 2016 at 3:17 PM
To: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>
Subject: Re: CFLAA
Hi!
> I see there is on going work with alias
2017 May 16
2
ThinLTO with Linux+ELF+Gold -- incorrectly dropping weak definitions.
This looks similar to the problem I fixed awhile back in r292408. I'll take
a look (probably tomorrow since I am taking some vacation today).
Teresa
On Tue, May 16, 2017 at 9:43 AM, David Blaikie <dblaikie at gmail.com> wrote:
> +Teresa
>
> On Mon, May 15, 2017 at 9:20 AM David Callahan via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I am tracking a
2016 Aug 25
2
CFLAA
I did gathered aggregate statistics reported by “-stats” over the ~400 test files.
The following table summarizes the impact. The first column is the
sum where the new analysis is enabled, the second column is the
delta from baseline where no CFL alias analysis is performed. I am not
experienced enough to know which of these are “good” or “bad” indicators.
—david
72,250 685 SLP
2016 Aug 26
3
CFLAA
Hi David,
I am the one who's responsible for CFLAA's refactoring in the summer.
I've sent out another email on llvm-dev, and you can find more about my
work in my GSoC final report.
I think it is fantastic that you have done such an interesting work.
I'll definitely try to help getting the code reviewed and merged in the
current. After a quick glance at your patch, it seems