Hi,
I would like to understand better the meaning of constant null pointer in LLVM
IR.
Can the optimizer assume that dereferencing a null pointer is always
unreachable? Or is it only the case for address space 0? Is it ok to have null
pointer be a valid pointer for an address space other than 0?
In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I see that
we replace load of null pointer by unreachable only for address space 0. But
there is also code doing the following transformation for all the address
spaces:
      // load (select (cond, null, P)) -> load P
      if(isa<ConstantPointerNull>(SI->getOperand(1)) &&
          LI.getPointerAddressSpace() == 0) {
        LI.setOperand(0, SI->getOperand(2));
        return &LI;
      }
Is this a bug? Would the correct behavior be to check that the pointers'
address space is 0?
Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/caeab170/attachment.html>
----- Original Message -----> From: "Thomas F Raoux" <thomas.f.raoux at intel.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, December 11, 2014 1:03:39 PM > Subject: [LLVMdev] Dereferencing null pointers > > Hi, > > I would like to understand better the meaning of constant null > pointer in LLVM IR. > > > > Can the optimizer assume that dereferencing a null pointer is always > unreachable? Or is it only the case for address space 0? Is it ok to > have null pointer be a valid pointer for an address space other than > 0?Correct, it is valid to have a null pointer dereference in address spaces other than 0.> > > > In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I > see that we replace load of null pointer by unreachable only for > address space 0. But there is also code doing the following > transformation for all the address spaces: > > // load (select (cond, null, P)) -> load P > > if(isa<ConstantPointerNull>(SI->getOperand(1)) && > > LI.getPointerAddressSpace() == 0) { > > LI.setOperand(0, SI->getOperand(2)); > > return &LI; > > } > > > > Is this a bug? Would the correct behavior be to check that the > pointers’ address space is 0?But it does, no? it has && LI.getPointerAddressSpace() == 0 -Hal> > > > Cheers, > > Thomas > > > _______________________________________________ > 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
Sorry for the confusion, I pasted the code I fixed locally...
Here is the code at top of the trunk:
      // load (select (cond, null, P)) -> load P
      if (Constant *C = dyn_cast<Constant>(SI->getOperand(1)))
        if (C->isNullValue()) {
          LI.setOperand(0, SI->getOperand(2));
          return &LI;
        }
So it is a bug?
-----Original Message-----
From: Hal Finkel [mailto:hfinkel at anl.gov] 
Sent: Thursday, December 11, 2014 11:13 AM
To: Raoux, Thomas F
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Dereferencing null pointers
----- Original Message -----> From: "Thomas F Raoux" <thomas.f.raoux at intel.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Thursday, December 11, 2014 1:03:39 PM
> Subject: [LLVMdev] Dereferencing null pointers
> 
> Hi,
> 
> I would like to understand better the meaning of constant null pointer 
> in LLVM IR.
> 
> 
> 
> Can the optimizer assume that dereferencing a null pointer is always 
> unreachable? Or is it only the case for address space 0? Is it ok to 
> have null pointer be a valid pointer for an address space other than 
> 0?
Correct, it is valid to have a null pointer dereference in address spaces other
than 0.
> 
> 
> 
> In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I see 
> that we replace load of null pointer by unreachable only for address 
> space 0. But there is also code doing the following transformation for 
> all the address spaces:
> 
> // load (select (cond, null, P)) -> load P
> 
> if(isa<ConstantPointerNull>(SI->getOperand(1)) &&
> 
> LI.getPointerAddressSpace() == 0) {
> 
> LI.setOperand(0, SI->getOperand(2));
> 
> return &LI;
> 
> }
> 
> 
> 
> Is this a bug? Would the correct behavior be to check that the 
> pointers’ address space is 0?
But it does, no? it has && LI.getPointerAddressSpace() == 0
 -Hal
> 
> 
> 
> Cheers,
> 
> Thomas
> 
> 
> _______________________________________________
> 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