Yes, you are right. The decl_or_value take first works well, missed this detail in previous and updated the PATCH v5 for this. Thank you!
Pan -----Original Message----- From: Richard Sandiford <richard.sandif...@arm.com> Sent: Thursday, May 11, 2023 12:43 PM To: Li, Pan2 <pan2...@intel.com> Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang <yanzhang.w...@intel.com>; jeffreya...@gmail.com; ja...@redhat.com; rguent...@suse.de Subject: Re: [PATCH v3] Var-Tracking: Typedef pointer_mux<tree_node, rtx_def> as decl_or_value "Li, Pan2" <pan2...@intel.com> writes: > Thanks Richard Sandiford. Update PATCH v4 here -> > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618099.html. > >> - if (dv_as_opaque (node->dv) != decl || node->offset != offset) >> + if (node->dv.first_or_null () != decl || node->offset != >> + offset) > >> Genuine question, but: is the first_or_null really needed? I would have >> expected node->dv != decl to work, with an implicit conversion on the >> argument. > > Directly compare node->dv and decl may requires additional overload operator, > or it may complains similar as below. But I am afraid it is unreasonable to > add such kind of operator for one specific type RTX in pointer_mux up to a > point. Thus I think here we may need node->dv == (decl_or_val) decl here. > > ../../gcc/var-tracking.cc:3233:28: error: no match for 'operator!=' (operand > types are 'rtx' {aka 'rtx_def*'} and 'decl_or_value' {aka > 'pointer_mux<tree_node, rtx_def>'}). Yeah, since we're adding operator== and operator!= as member operators, the decl_or_value has to come first. Please try the conditions in the order that I'd written them in the review. Thanks, Richard
