[LLVMdev] Telling the optimizer a value is always null at the start

Hal Finkel hfinkel at anl.gov
Mon Jul 14 11:40:08 PDT 2014


----- Original Message -----
> From: "Stephan Tolksdorf" <st at quanttec.com>
> To: "Carlo Kok" <ck at remobjects.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, July 14, 2014 1:06:33 PM
> Subject: Re: [LLVMdev] Telling the optimizer a value is always null at the start
> 
> On 2014-07-13 16:50, Carlo Kok wrote:
> >   On Thu, Jul 10, 2014 at 11:29 AM, Philip Reames
> >   <listmail at philipreames.com> wrote:
> >> Hm, I don't know of an explicit way in the IR to do this.  If
> >> anyone else
> >> does, feel free to chime in.
> >>
> >> One approach would be to add a branch at the beginning of the
> >> function
> >> to an
> >> unreachable block.  If you're testeh function started with:
> >> if( *ex != null) llvm_unreachable();
> >>
> >> You might get lucky and have the GVN or EarlyCSE propagate the
> >> null
> >> value.
> >> You're going to run into pass ordering problems here though.  I
> >> suspect we'd
> >> drop the unreachable block before GVN runs.
> >
> > Looks like, at least I tried the code below and while it removes
> > the
> > unreachable, it doesn't remove the second checck. Philips code
> > looks
> > like it could do this though.
> 
> LLVM's can't exploit information introduced by unreachable() like GCC
> can (or like MSVC can for the equivalent __assume() expression). This
> has been a long-standing issue, see the later comments in
> http://llvm.org/bugs/show_bug.cgi?id=810

FYI: I've started posting patches to the llvm-commits list for review which implement an 'invariants' intrinsic which will address this shortcoming.

 -Hal

> 
> - Stephan
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list