All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code
Date: Fri, 17 May 2019 22:23:40 +0000	[thread overview]
Message-ID: <1558131743.2682.33.camel@synopsys.com> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA2307501A2517B16@us01wembx1.internal.synopsys.com>

Hmmm,

so load the bool variable from memory is converted to such asm code:

----------------->8------------------- 
ldb	r2,[some_bool_address]
extb_s	r2,r2
----------------->8-------------------

Could you please describe that the magic is going on there?

This extb_s instruction looks completely useless here, according on the LDB description from PRM:
----------------->8-------------------
LD LDH LDW LDB LDD:
The size of the requested data is specified by the data size field <.zz> and by default, data is zero
extended from the most-significant bit of the data to the most-significant bit of the destination
register.
----------------->8-------------------

Am I missing something?

On Thu, 2019-05-16@17:37 +0000, Vineet Gupta wrote:
> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
> > > +    unsigned int write = 0, exec = 0, mask;
> > 
> > Probably it's better to use 'bool' type for 'write' and 'exec' as we really use them as a boolean variables.
> 
> Right those are semantics, but the generated code for "bool" is not ideal - given
> it is inherently a "char" it is promoted first to an int with an additional EXTB
> which I really dislike.
> Guess it is more of a style thing.
> 
> -Vineet
-- 
 Eugeniy Paltsev

WARNING: multiple messages have this Message-ID (diff)
From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: "paltsev@snyopsys.com" <paltsev@snyopsys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code
Date: Fri, 17 May 2019 22:23:40 +0000	[thread overview]
Message-ID: <1558131743.2682.33.camel@synopsys.com> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA2307501A2517B16@us01wembx1.internal.synopsys.com>

Hmmm,

so load the bool variable from memory is converted to such asm code:

----------------->8------------------- 
ldb	r2,[some_bool_address]
extb_s	r2,r2
----------------->8-------------------

Could you please describe that the magic is going on there?

This extb_s instruction looks completely useless here, according on the LDB description from PRM:
----------------->8-------------------
LD LDH LDW LDB LDD:
The size of the requested data is specified by the data size field <.zz> and by default, data is zero
extended from the most-significant bit of the data to the most-significant bit of the destination
register.
----------------->8-------------------

Am I missing something?

On Thu, 2019-05-16 at 17:37 +0000, Vineet Gupta wrote:
> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
> > > +    unsigned int write = 0, exec = 0, mask;
> > 
> > Probably it's better to use 'bool' type for 'write' and 'exec' as we really use them as a boolean variables.
> 
> Right those are semantics, but the generated code for "bool" is not ideal - given
> it is inherently a "char" it is promoted first to an int with an additional EXTB
> which I really dislike.
> Guess it is more of a style thing.
> 
> -Vineet
-- 
 Eugeniy Paltsev

  parent reply	other threads:[~2019-05-17 22:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15  0:29 [PATCH 0/9] ARC do_page_fault rework Vineet Gupta
2019-05-15  0:29 ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 1/9] ARC: mm: SIGSEGV userspace trying to access kernel virtual memory Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15 10:54   ` Sasha Levin
2019-05-15  0:29 ` [PATCH 2/9] ARC: mm: do_page_fault refactor #1: remove label @good_area Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 3/9] ARC: mm: do_page_fault refactor #2: remove short lived variable Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-16 17:24   ` Eugeniy Paltsev
2019-05-16 17:24     ` Eugeniy Paltsev
2019-05-16 17:37     ` Vineet Gupta
2019-05-16 17:37       ` Vineet Gupta
2019-05-16 17:44       ` Alexey Brodkin
2019-05-16 17:44         ` Alexey Brodkin
2019-05-16 18:57         ` Vineet Gupta
2019-05-16 18:57           ` Vineet Gupta
2019-05-17 22:23       ` Eugeniy Paltsev [this message]
2019-05-17 22:23         ` Eugeniy Paltsev
2019-05-30 17:58         ` extraneous generated EXTB (was Re: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code) Vineet Gupta
2019-05-30 17:58           ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 5/9] ARC: mm: do_page_fault refactor #4: consolidate retry related logic Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 6/9] ARC: mm: do_page_fault refactor #5: scoot no_context to end Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 7/9] ARC: mm: do_page_fault refactor #6: error handlers to use same pattern Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 8/9] ARC: mm: do_page_fault refactor #7: fold the various error handling Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-15  0:29 ` [PATCH 9/9] ARC: mm: do_page_fault refactor #8: release mmap_sem sooner Vineet Gupta
2019-05-15  0:29   ` Vineet Gupta
2019-05-30 16:48   ` Vineet Gupta
2019-05-30 16:48     ` Vineet Gupta

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=1558131743.2682.33.camel@synopsys.com \
    --to=eugeniy.paltsev@synopsys.com \
    --cc=linux-snps-arc@lists.infradead.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.