This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/9] Come up with an abstraction.


On Wed, Sep 18, 2019 at 9:56 AM Martin Liška <mliska@suse.cz> wrote:
>
> Hello.
>
> Ok, so the current IPA ICF transformation is being blocked by the
> patch 2/9 (about FIELD_DECL). I asked Honza for a help here.
> In the meantime, can you Richi make an opinion about the part 5 which
> is about the interaction in between old operand_equal_p and a new
> hook in IPA ICF?

+static operand_compare default_compare_instance;
+
+/* Conveinece wrapper around operand_compare class because usually we do
+   not need to play with the valueizer.  */
+
+bool
+operand_equal_p (const_tree arg0, const_tree arg1, unsigned int flags)
+{
+  return default_compare_instance.operand_equal_p (arg0, arg1, flags);
+}

can we devirtualize this and thus further clone and devirtualize the
recursions in the default instance?  if not does making the default
instance const help (you need to make the methods const, possibly
a good idea if that works for your ICF use as well?)

+  if (flag_checking && !(flags & OEP_NO_HASH_CHECK))
+    {

better keep that in the caller (avoids the virtual call and also
then the function does what it says...).

Otherwise it looks OK.  Note I'd really like to see the
overhead for the regular operand_equal_p calls being zero,
thus devirt is important here - but it should work with
IPA-CP of 'this'?  But maybe the function is too big to
clone :/

Richard.

> Thanks,
> Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]