[Ingo Molnar - Mon, Dec 17, 2007 at 05:01:27PM +0100]
|
| * Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
|
| > Checkpatch still does complain about
| > if (0) { T__ tmp__; tmp__ = (val)
| > I'm not sure if we need this line at all.
|
| that's a type-checking trick. It does not result in any
* Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Checkpatch still does complain about
> if (0) { T__ tmp__; tmp__ = (val)
> I'm not sure if we need this line at all.
that's a type-checking trick. It does not result in any generated code
but gcc flags it with a build time warning if there's
* Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Hi, I've tried to make a one ;) It's over last (today synced) linus
> tree.
thanks, applied :-)
Some small details: i had to hand-apply your patch to the x86.git#mm
tree (see the instructions below how to fetch that tree). It's best (for
us
[Ingo Molnar - Mon, Dec 17, 2007 at 03:53:17PM +0100]
|
| * Jan Beulich <[EMAIL PROTECTED]> wrote:
|
| > > good catch! Applied your patch to x86.git - queued it up for
| > > v2.6.25. I bet there are tons of other instances where we use signed
| > > instead of unsigned and get worse code
* Jan Beulich <[EMAIL PROTECTED]> wrote:
> > good catch! Applied your patch to x86.git - queued it up for
> > v2.6.25. I bet there are tons of other instances where we use signed
> > instead of unsigned and get worse code generation.
>
> Yes, definitely. This patch was kind of a testing one
>>> Ingo Molnar <[EMAIL PROTECTED]> 17.12.07 14:26 >>>
>
>* Jan Beulich <[EMAIL PROTECTED]> wrote:
>
>> This generally allows better code to be generated, since the zero-
>> extension during 32-bit operations comes for free (needed when the
>> result is used as array index or similar), whereas
* Jan Beulich <[EMAIL PROTECTED]> wrote:
> This generally allows better code to be generated, since the zero-
> extension during 32-bit operations comes for free (needed when the
> result is used as array index or similar), whereas sign extension must
> be done explicitly and frequently
* Jan Beulich [EMAIL PROTECTED] wrote:
This generally allows better code to be generated, since the zero-
extension during 32-bit operations comes for free (needed when the
result is used as array index or similar), whereas sign extension must
be done explicitly and frequently requires a
Ingo Molnar [EMAIL PROTECTED] 17.12.07 14:26
* Jan Beulich [EMAIL PROTECTED] wrote:
This generally allows better code to be generated, since the zero-
extension during 32-bit operations comes for free (needed when the
result is used as array index or similar), whereas sign extension must
* Jan Beulich [EMAIL PROTECTED] wrote:
good catch! Applied your patch to x86.git - queued it up for
v2.6.25. I bet there are tons of other instances where we use signed
instead of unsigned and get worse code generation.
Yes, definitely. This patch was kind of a testing one whether
[Ingo Molnar - Mon, Dec 17, 2007 at 03:53:17PM +0100]
|
| * Jan Beulich [EMAIL PROTECTED] wrote:
|
| good catch! Applied your patch to x86.git - queued it up for
| v2.6.25. I bet there are tons of other instances where we use signed
| instead of unsigned and get worse code generation.
|
* Cyrill Gorcunov [EMAIL PROTECTED] wrote:
Hi, I've tried to make a one ;) It's over last (today synced) linus
tree.
thanks, applied :-)
Some small details: i had to hand-apply your patch to the x86.git#mm
tree (see the instructions below how to fetch that tree). It's best (for
us
* Cyrill Gorcunov [EMAIL PROTECTED] wrote:
Checkpatch still does complain about
if (0) { T__ tmp__; tmp__ = (val)
I'm not sure if we need this line at all.
that's a type-checking trick. It does not result in any generated code
but gcc flags it with a build time warning if there's a
[Ingo Molnar - Mon, Dec 17, 2007 at 05:01:27PM +0100]
|
| * Cyrill Gorcunov [EMAIL PROTECTED] wrote:
|
| Checkpatch still does complain about
| if (0) { T__ tmp__; tmp__ = (val)
| I'm not sure if we need this line at all.
|
| that's a type-checking trick. It does not result in any
This generally allows better code to be generated, since the zero-
extension during 32-bit operations comes for free (needed when the
result is used as array index or similar), whereas sign extension must
be done explicitly and frequently requires a one byte larger
instruction due to the necessary
This generally allows better code to be generated, since the zero-
extension during 32-bit operations comes for free (needed when the
result is used as array index or similar), whereas sign extension must
be done explicitly and frequently requires a one byte larger
instruction due to the necessary
16 matches
Mail list logo