[llvm] r214452 - Make classof in MemSDNode consistent with MemIntrinsicSDNode

Hal Finkel hfinkel at anl.gov
Tue Aug 12 18:30:36 PDT 2014


----- Original Message -----
> From: "Hal J. Finkel" <hfinkel at anl.gov>
> To: "Matt Arsenault" <arsenm2 at gmail.com>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Wednesday, August 6, 2014 11:22:05 AM
> Subject: Re: [llvm] r214452 - Make classof in MemSDNode consistent with	MemIntrinsicSDNode
>
> Hi Matt,
> 
> 
> Thanks for pointing this out. Unfortunately, it looks like we'll need
> to do some cleanup here. The class hierarchy is what it is, and the
> debug code like this is going to need to be changed to not
> unconditionally dereference the MMO.
> 
> 
> I'll fix it this weekend or early next week.

r215511 should fix the underlying problem, thanks for finding this!

 -Hal

> 
> 
> -Hal
> 
> 
> Sent from my Verizon Wireless 4G LTE DROID
> 
> Matt Arsenault <arsenm2 at gmail.com> wrote:
> 
> 
> 
> On Jul 31, 2014, at 3:31 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > Author: hfinkel
> > Date: Thu Jul 31 17:31:33 2014
> > New Revision: 214452
> > 
> > URL: http://llvm.org/viewvc/llvm-project?rev=214452&view=rev
> > Log:
> > Make classof in MemSDNode consistent with MemIntrinsicSDNode
> > 
> > If INTRINSIC_W_CHAIN and INTRINSIC_VOID are MemIntrinsicSDNodes,
> > and a
> > MemIntrinsicSDNode is a MemSDNode, then INTRINSIC_W_CHAIN and
> > INTRINSIC_VOID
> > must be MemSDNodes too.
> > 
> > Noticed by inspection.
> > 
> > Modified:
> > llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
> > 
> > Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
> > URL:
> > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h?rev=214452&r1=214451&r2=214452&view=diff
> > ==============================================================================
> > --- llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h (original)
> > +++ llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h Thu Jul 31
> > 17:31:33 2014
> > @@ -1158,6 +1158,8 @@ public:
> > N->getOpcode() == ISD::ATOMIC_LOAD_UMAX ||
> > N->getOpcode() == ISD::ATOMIC_LOAD ||
> > N->getOpcode() == ISD::ATOMIC_STORE ||
> > + N->getOpcode() == ISD::INTRINSIC_W_CHAIN ||
> > + N->getOpcode() == ISD::INTRINSIC_VOID ||
> > N->isTargetMemoryOpcode();
> > }
> > };
> > 
> 
> 
> This is breaking SI with -debug, trying to access a nonexistent
> memoperand:
> 
> } else if (const MemSDNode* M = dyn_cast<MemSDNode>(this)) {
> OS << "<" << *M->getMemOperand() << ">";
> 
> If you run any test that uses some of the control flow intrinsics,
> this crashes when calling dump() on the node. These intrinsics have
> chains, but do not have any specific memory operand to be associated
> with. Is there something wrong with the current definitions for
> these? (e.g. int_SI_if)
> 
> To reproduce, run llc -debug -march=r600 -mcpu=tahiti
> test/CodeGen/R600/add.ll
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

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



More information about the llvm-commits mailing list