similar to: [LLVMdev] interprocedural live value analysis

Hi all, I had a look at the interprocedural optimizer. In my opinion the routine 'GlobalOpt::ProcessInternalGlobal' is a little bit to conservative. It removes global variables if the only routine using this variable is main. Typically this condition is valid only for very few global variables. Here is a code snippet containing the test before the transformation: file:

On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote: > By static array bounds checking, I mean eliminating array bounds > checking > which can be proved ``safe'' at compile-time. Even though SAFECode does have such a pass, there are some tradeoffs with the current version: 1. It uses an external solver (Omega), which is one more dependence for LLVM in general. I don't have

Hi Fahad, > > Improve dynamic memory related capabilities of Attributor. For example > Improve HeapToStackConversions. Maybe such deductions can help safety > (dis)provers. For example, can we improve the use-after-free bug detection > using some attributes? > Stefan should know more about H2S. Regarding the use-after-free, I don't > think there's currently any plans

> You can solve andersens and steengaards and everything else using > standard dataflow solvers, and that's an implementation strategy, but > it will be really slow. > > Part of the tradeoff is how fast something runs, and approaches that > are orders of magnitude faster often change the calculus of what > people do. For example, before hardekopf's work, andersens

Hello, I need interprocedural alias analysis while I'm using GVN for infeasible path analysis. So, I've tried "-steens-aa" from poolalloc project, but it doesn't seem to be working as I expected. For example, int global; int bar(void) { return 5; } int foo(void) { int a; scanf("%d", &a); if(global) a = bar(); return a; } In this case, I

R gurus, Every so often(*) someone asks how to suppress scientific notation in printing, so I thought I'd give it a shot, but I need some help. The formatting decision is made(**) on line 286 of src/main/format.c : if (mF <= *m) { /* IFF it needs less space : "F" (Fixpoint) format */ where mF is the number of characters for "normal" printing and *m is the number

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On

On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 10:38 AM,

On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM

On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 10:39 AM, Hiroshi

Hi. I'm sending this email to -dev as this may be of interest of many/people may have opinions/want to try the change before it goes in to report problems. I've been recently working on a patch to integrate `undef` in the SCCP solver, in the hope of fixing a tail of latent bugs in SCCP which remained uncovered for many years. I think this is a decent time to propose, so that it can

On Thu, Jul 6, 2017 at 7:00 AM, Davide Italiano <davide at freebsd.org> wrote: > On Wed, Jul 5, 2017 at 3:59 PM, Johan Engelen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I just found an optimization regression regarding simple > > dataflow/constprop analysis: > > https://godbolt.org/g/Uz8P7t > > > > This code >

If I turn on one of the llvm interprocedural optimizations without turning on the analysis it uses. will the analysis be turned on automatically ? Thanks Xin

On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> ( >>> ​I came across this issue in

Hi Farad, > I tried to do this for the NoUnwind attribute Hmm, I don't have experience with this attribute but it seems like a good starting point since it doesn't do much. First of all, be sure that you run with: opt -passes=attributor -attributor-disable=false This uses the new pass manager which is another discussion. Now, to the point: If you open nounwind.ll, it has a bunch of

There is/are implicit dependency for the optimization on its analysis. So, if you run the optimization, the analysis will be turned on implicitly, through the PassManager. Chuck On 2/12/2012 10:10 AM, Xin Tong wrote: > If I turn on one of the llvm interprocedural optimizations without > turning on the analysis it uses. will the analysis be turned on > automatically ? > > Thanks

http://dl.acm.org/citation.cfm?id=2843863 Luke Jones, Ryan Whelan, Jeremy Blackthorne, and Graham Baker. 2015. Flowtables: Program Skeletal Inversion for Defeat of Interprocedural Analysis with Unique Metamorphism. In Proceedings of the 5th Program Protection and Reverse Engineering Workshop (PPREW-5). ACM, New York, NY, USA, , Article 6 , 11 pages. DOI=http://dx.doi.org/10.1145/2843859.2843863

On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin > <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: > > > > On Thu, May

On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 8:24

Hi David, Looking at the original bug, it seems like a straightforward undef-propagation bug to me -- SCCP was folding "or undef, constant" to "undef", which is wrong. Why is changing that not the fix? That is, some variant of diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++