similar to: [LLVMdev] [llvm] r175553 - Fix a bug in mayHaveSideEffects. Functions that do not return are now considered as instructions with side effects.

Currently LLVM removes infinite recursion in readnone functions as dead code. I assume this falls under the same language rules that allow removal of infinite loops. But I need to be certain. Can someone confirm? Standard citations welcome. Otherwise this is wrong: bool mayHaveSideEffects() const { return mayWriteToMemory() || mayThrow() || !mayReturn(); } Note: For non-C support, it

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write

Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev]

> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: >> >> On 19.03.2016 16:25, Mehdi Amini wrote: >>> Hi, >>> >>> Can you elaborate what is the impact at the IR level? >>> If the point is just about

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

On 19.03.2016 16:25, Mehdi Amini wrote: > Hi, > > Can you elaborate what is the impact at the IR level? > If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes. As I explained in my reply to Philip, what I really need is a way to get

While improving ADCE, i notice that for declare i32 @strlen(i8*) readnone define i32 @test() { ; invoke of pure function should not be deleted! invoke i32 @strlen( i8* null ) readnone to label %Cont unwind label %Other ; <i32>:1 [#uses=0] Cont: ; preds = %0 ret i32 0 Other: ; preds = %0 %exn = landingpad {i8*, i32} personality i32 (...)* @__gxx_personality_v0

Hi, List, As you may know, BCC of android makes use of LLVM's major components. Its LTO actually selects some optimizations of LLVM. I found it can not only use "-functionattrs". I must first use -argpromotion first, or I end up this error: Pass 'Deduce function attributes' is not initialized. Verify if there is a pass dependency cycle. Required Passes: bcc:

Here's a version that doesn't try to do block deletion on it's own. If you use -adce then -simplifycfg, you get what you want. It passes all tests except one, which is that we delete an invoke of a pure function, IE Transforms/ADCE/dce_pure_invoke.ll - I'm not sure why that's bad. The reason we delete it is because it returns false to I.mayHaveSideEffects(), and in particular,

After I spend some time working with the function attribute* deduction pass** [1,3], I would like to propose a "proper" organization***. Why? Because we do not derive nearly as many attributes as we could****, while we do maintain various (separate and diffently organized) "data-flow-like analyses" to do so. What else? I propose a single optimistic data-flow

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

Hi Andrew, On 22/07/13 09:32, Andrew Trick wrote: > > On Jul 21, 2013, at 11:55 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > >> Hi Andrew, >> >> On 22/07/13 02:56, Andrew Trick wrote: >>> Does 'nounwind' have semantics that inform optimization passes? It seems to >>> in some cases, but not

----- Original Message ----- > > > > On Nov 1, 2013, at 4:48 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > 3. Represent the control dependencies explicitly in the metadata. > Andy, Arnold (CC'd) and I have been discussing this in a > slightly-different context, and briefly, this means adding all of > the relevant conditional branch inputs to the

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

On Thu, Jul 21, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 21, 2016 at 9:26 AM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> >> wrote: >> >> Joining in very late, but the tangent here has been interesting (if >>

On Jul 21, 2013, at 11:55 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Andrew, > > On 22/07/13 02:56, Andrew Trick wrote: >> Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... >> >> int32_t foo(int32_t* ptr) { >> int i = 0; >> int result; >> do {

On Nov 1, 2013, at 4:48 AM, Hal Finkel <hfinkel at anl.gov> wrote: > 3. Represent the control dependencies explicitly in the metadata. Andy, Arnold (CC'd) and I have been discussing this in a slightly-different context, and briefly, this means adding all of the relevant conditional branch inputs to the metadata, and ensuring dominance before the metadata is respected. For example:

Thanks for the answer Nick. Now you got me on a chase through FunctionAttrs.cpp trying to find out what analysis passes "... which answers no to everything", means. :-) Garrison On Sep 10, 2011, at 13:52, Nick Lewycky wrote: > Nick Lewycky wrote: >> I was sure that I remember "opt -functionattrs" being taught to do this, >> but I just tried it out and it

On 2009-06-29 11:16, Wenzhi Tao wrote: > Hi, all > > According to the document "LLVM Alias Analysis Infrastructure", I > evaluated the AA performance by using the paramenters '-basicaa -ds-aa > -anders-aa'. The source code 'test.c' is listed as follow: > [...] > The whole process: > > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc > > opt

Hi, Thanks for your advice. I have tried this way: opt -mem2reg test.bc -o mem2reg.bc llvm-dis mem2reg.bc opt -functionattrs -basicaa -aa-eval -print-all-alias-modref-info mem2reg.bc The content of main() in mem2reg.ll: define i32 @main() nounwind { entry: %"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0] %0 = call %struct.Location* @getNewLocation(i32 0, i32