[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e76d2db0-14e9-2c65-947d-a2c1ccc7b832@synopsys.com>
Date: Thu, 16 May 2019 11:57:16 -0700
From: Vineet Gupta <Vineet.Gupta1@...opsys.com>
To: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
CC: Claudiu Zissulescu <Claudiu.Zissulescu@...opsys.com>,
"paltsev@...opsys.com" <paltsev@...opsys.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
Subject: Re: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access
permission code
On 5/16/19 10:44 AM, Alexey Brodkin 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.
>
> In that sense maybe think about re-definition of "bool" type to 32-bit one
> for entire architecture and get that benefit across the entire source tree?
what bool maps to is driven by the ABI and while not explicit in the ARCv2 ABI
doc, I guess it is byte and hence can't be changed just like that.
-Vineet
Powered by blists - more mailing lists