public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Caroline Tice <cmtice@google.com>
To: Lulu Cheng <chenglulu@loongson.cn>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	mliska@suse.cz,  David Malcolm <dmalcolm@redhat.com>,
	qijingwen <qijingwen@loongson.cn>,
	xuchenghua@loongson.cn,  i@xen0n.name
Subject: Re: [PATCH v2] LoongArch: Libvtv add loongarch support.
Date: Tue, 11 Oct 2022 13:57:54 -0700	[thread overview]
Message-ID: <CABtf2+TktYXnDASpRH-WtzoULcJwDe0PxwaHebuWyZry87gBDw@mail.gmail.com> (raw)
In-Reply-To: <20220927074928.804896-1-chenglulu@loongson.cn>

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

I think that if VTV_PAGE_SIZE is not set to the actual size being used by
the system,  it could result in some unexpected failures.  I believe the
right thing to do in this case, since the size may vary, is to get the
actual size being used by the system and use that in the definition of
VTV_PAGE_SIZE.  So in include/vtv-permission.h you would have something
like:

+#elif defined(__loongarch_lp64)
+#define VTV_PAGE_SIZE sysconf(_SC_PAGE_SIZE)

Then you would have the accurate, correct size for the current system, and
there would be no need to update the
check in vtv_malloc.cc at all.

-- Caroline Tice
cmtice@google.com

On Tue, Sep 27, 2022 at 3:04 AM Lulu Cheng <chenglulu@loongson.cn> wrote:

>
> v1 - > v2:
>
> 1. When the macro __loongarch_lp64 is defined, the VTV_PAGE_SIZE is set to
> 64K.
> 2. In the vtv_malloc.cc file __vtv_malloc_init function, it does not check
>    whether VTV_PAGE_SIZE is equal to the system page size, if the macro
>    __loongarch_lp64 is defined.
>
> All regression tests of libvtv passed.
>
>                 === libvtv Summary ===
>
> # of expected passes            176
>
> But I haven't tested the performance yet.
>
> -----------------------------------
> Co-Authored-By: qijingwen <qijingwen@loongson.cn>
>
> include/ChangeLog:
>
>         * vtv-change-permission.h (defined):
>         (VTV_PAGE_SIZE): Under the loongarch64 architecture,
>         set VTV_PAGE_SIZE to 64K.
>
> libvtv/ChangeLog:
>
>         * configure.tgt: Add loongarch support.
>         * vtv_malloc.cc (defined): If macro __loongarch_lp64 is
>         defined, then don't check whether VTV_PAGE_SIZE is the
>         same as the system page size.
> ---
>  include/vtv-change-permission.h | 4 ++++
>  libvtv/configure.tgt            | 3 +++
>  libvtv/vtv_malloc.cc            | 5 +++++
>  3 files changed, 12 insertions(+)
>
> diff --git a/include/vtv-change-permission.h
> b/include/vtv-change-permission.h
> index 70bdad92bca..64e419c29d5 100644
> --- a/include/vtv-change-permission.h
> +++ b/include/vtv-change-permission.h
> @@ -48,6 +48,10 @@ extern void __VLTChangePermission (int);
>  #else
>  #if defined(__sun__) && defined(__svr4__) && defined(__sparc__)
>  #define VTV_PAGE_SIZE 8192
> +/* LoongArch architecture 64-bit system supports 4k,16k and 64k
> +   page size, which is set to the maximum value here.  */
> +#elif defined(__loongarch_lp64)
> +#define VTV_PAGE_SIZE 65536
>  #else
>  #define VTV_PAGE_SIZE 4096
>  #endif
> diff --git a/libvtv/configure.tgt b/libvtv/configure.tgt
> index aa2a3f675b8..6cdd1e97ab1 100644
> --- a/libvtv/configure.tgt
> +++ b/libvtv/configure.tgt
> @@ -50,6 +50,9 @@ case "${target}" in
>         ;;
>    x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
>         ;;
> +  loongarch*-*-linux*)
> +       VTV_SUPPORTED=yes
> +       ;;
>    *)
>         ;;
>  esac
> diff --git a/libvtv/vtv_malloc.cc b/libvtv/vtv_malloc.cc
> index 67c5de6d4e9..45804b8d7f8 100644
> --- a/libvtv/vtv_malloc.cc
> +++ b/libvtv/vtv_malloc.cc
> @@ -212,6 +212,11 @@ __vtv_malloc_init (void)
>
>  #if defined (__CYGWIN__) || defined (__MINGW32__)
>    if (VTV_PAGE_SIZE != sysconf_SC_PAGE_SIZE())
> +#elif defined (__loongarch_lp64)
> +  /* I think that under the LoongArch 64-bit system, VTV_PAGE_SIZE is set
> +     to the maximum value of 64K supported by the system, so there is no
> +     need to judge here.  */
> +  if (false)
>  #else
>    if (VTV_PAGE_SIZE != sysconf (_SC_PAGE_SIZE))
>  #endif
> --
> 2.31.1
>
>

  parent reply	other threads:[~2022-10-11 20:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-27  7:49 Lulu Cheng
2022-09-27 11:44 ` Xi Ruoyao
2022-09-28  7:29   ` Lulu Cheng
2022-10-10 17:49 ` Caroline Tice
2022-10-11  9:41   ` Xi Ruoyao
2022-10-11 20:57 ` Caroline Tice [this message]
2022-10-12  2:52   ` Lulu Cheng
2022-10-12  4:05     ` Caroline Tice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABtf2+TktYXnDASpRH-WtzoULcJwDe0PxwaHebuWyZry87gBDw@mail.gmail.com \
    --to=cmtice@google.com \
    --cc=chenglulu@loongson.cn \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=i@xen0n.name \
    --cc=mliska@suse.cz \
    --cc=qijingwen@loongson.cn \
    --cc=xuchenghua@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).