[LLVMdev] All CallInsts mayHaveSideEffects

Samuel Crow samuraileumas at yahoo.com
Mon May 10 19:36:25 PDT 2010


I'd imagine every get method in any C++ program would benefit from that sort of dead-code elimination.  Although simply inlining it might might be all that's really needed.



----- Original Message ----
> From: Thomas B. Jablin <tjablin at cs.princeton.edu>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Mon, May 10, 2010 9:01:09 PM
> Subject: Re: [LLVMdev] All CallInsts mayHaveSideEffects
> 
> Does any real code benefit from dead code eliminating read-only 
> functions?
Tom

----- Original Message -----
From: "Reid Kleckner" 
> <
> href="mailto:rnk at mit.edu">rnk at mit.edu>
To: "Thomas B. Jablin" <
> ymailto="mailto:tjablin at CS.Princeton.EDU" 
> href="mailto:tjablin at CS.Princeton.EDU">tjablin at CS.Princeton.EDU>
Cc: 
> "LLVM Developers Mailing List" <
> href="mailto:llvmdev at cs.uiuc.edu">llvmdev at cs.uiuc.edu>
Sent: Monday, 
> May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern
Subject: Re: [LLVMdev] 
> All CallInsts mayHaveSideEffects

This is a known 
> bug:
http://llvm.org/bugs/show_bug.cgi?id=965

There has been some 
> discussion about it and similar problems, and the
desire is to perform some 
> analysis on functions to determine if they
are known to halt trivially, ie 
> they have no loops and call no other
functions that are not known to 
> halt.

LLVM still wants to be able to delete calls to trivial read-only 
> functions.

Reid

On Mon, May 10, 2010 at 8:28 PM, Thomas B. 
> Jablin
<
> href="mailto:tjablin at cs.princeton.edu">tjablin at cs.princeton.edu> 
> wrote:
> 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 to memory will be 
> dead code eliminated when the Inliner runs.
>
> Here is a simple 
> example of how things can go horribly wrong:
>
> #include 
> <stdio.h>
> #include <stdlib.h>
>
> void inf(void) 
> {
>  while(1);
> }
>
> int main(int argc, char **argv) 
> {
>  inf();
>  return 0;
> }
>
> void foo(void) 
> {
>  printf("Hello world!\n");
>  exit(0);
> }
>
> 
> For recent versions of clang (svn rev 102637) when compiled with -O1 or higher 
> the result is:
> Hello world!
>
> The reason is that LLVM 
> annotates inf as noreturn, so the ret instruction at the end of main is replaced 
> with unreachable. Then the inf function is dead-code eliminated by the Inliner 
> pass. Thus main will consist of a single unreachable instruction, which allows 
> control to fall through to the foo function.
>
> My suggested patch 
> is as follows:
>
> Index: include/llvm/Instruction.h
> 
> ===================================================================
> --- 
> include/llvm/Instruction.h  (revision 102637)
> +++ 
> include/llvm/Instruction.h  (working copy)
> @@ -245,7 +245,9 @@
>   
> /// instructions which don't used the returned value.  For cases where 
> this
>   /// matters, isSafeToSpeculativelyExecute may be more 
> appropriate.
>   bool mayHaveSideEffects() const {
> -    return 
> mayWriteToMemory() || mayThrow();
> +    const unsigned opcode = 
> getOpcode();
> +    return mayWriteToMemory() || mayThrow() ||
> +   
>    opcode == Call || opcode == Invoke;
>   }
>
>   /// 
> isSafeToSpeculativelyExecute - Return true if the instruction does 
> not
>
> Sincerely yours,
> Tom
> 
> _______________________________________________
> LLVM Developers mailing 
> list
> 
> href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu         
> http://llvm.cs.uiuc.edu
> 
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM 
> Developers mailing list

> href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu      
>   
> >http://llvm.cs.uiuc.edu

> href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target=_blank 
> >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


      



More information about the llvm-dev mailing list