All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Igor Druzhinin" <igor.druzhinin@citrix.com>,
	"Edwin Torok" <edvin.torok@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1.1 5/5] tests: Introduce a TSX test
Date: Mon, 14 Jun 2021 16:59:34 +0200	[thread overview]
Message-ID: <d7c7959c-6842-7305-2aef-77cb65883324@suse.com> (raw)
In-Reply-To: <cecc837c-e261-17d8-a77e-044256d8bc0b@citrix.com>

On 14.06.2021 16:50, Andrew Cooper wrote:
> On 14/06/2021 14:31, Jan Beulich wrote:
>> On 14.06.2021 12:47, Andrew Cooper wrote:
>>> +static void test_tsx(void)
>>> +{
>>> +    int rc;
>>> +
>>> +    /* Read all policies except raw. */
>>> +    for ( int i = XEN_SYSCTL_cpu_policy_host;
>> To avoid having this as bad precedent, even though it's "just" testing
>> code: unsigned int? (I've first spotted this here, but later I've
>> found more places elsewhere.)
> 
> Well - I question if it even is "bad" precedent.
> 
> For array bounds which are constants, the compiler can (and does) do
> better than anything we can write in C here, as it is arch-dependent
> whether signed or unsigned is better to use.
> 
> Beyond that, it's just code volume.

Well, no, I disagree. Any use of variables for array indexing,
when not intentionally meaning negative indexes as well, would
better use unsigned variables. This is just so that in cases
where it does matter, people will not end up cloning from an
instance where it may not be important because of, as you say,
e.g. constant loop bounds.

As to the compiler doing better - if it can when the induction
variable is (implicitly) signed, why would it not be able to
when the variable is (explicitly) unsigned?

Jan



  reply	other threads:[~2021-06-14 14:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 16:36 [PATCH 0/5] x86/tsx: Consistency and settings test Andrew Cooper
2021-06-11 16:36 ` [PATCH 1/5] x86/platform: Improve MSR permission handling for XENPF_resource_op Andrew Cooper
2021-06-14 12:45   ` Jan Beulich
2021-06-11 16:36 ` [PATCH 2/5] x86/platform: Permit reading the TSX control MSRs via XENPF_resource_op Andrew Cooper
2021-06-14 12:46   ` Jan Beulich
2021-06-11 16:36 ` [PATCH 3/5] x86/msr: Expose MSR_ARCH_CAPS in the raw and host policies Andrew Cooper
2021-06-14 12:57   ` Jan Beulich
2021-06-14 14:10     ` Andrew Cooper
2021-06-14 14:54       ` Jan Beulich
2021-06-11 16:36 ` [PATCH 4/5] libs/guest: Move struct xc_cpu_policy into xg_private.h Andrew Cooper
2021-06-14 13:00   ` Jan Beulich
2021-06-14 13:49     ` Ian Jackson
2021-06-14 13:56       ` Jan Beulich
2021-06-11 16:36 ` [PATCH 5/5] tests: Introduce a TSX test Andrew Cooper
2021-06-14 10:47   ` [PATCH v1.1 " Andrew Cooper
2021-06-14 13:31     ` Jan Beulich
2021-06-14 14:50       ` Andrew Cooper
2021-06-14 14:59         ` Jan Beulich [this message]
2021-06-14 15:55     ` Edwin Torok
2021-06-14 16:32       ` Andrew Cooper
2021-06-14 16:13   ` [PATCH v2 " Andrew Cooper
2021-06-14 17:21     ` Andrew Cooper
2021-06-15 13:49     ` Jan Beulich

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=d7c7959c-6842-7305-2aef-77cb65883324@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=edvin.torok@citrix.com \
    --cc=igor.druzhinin@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.