On 02/12/2013 10:46 AM, Linus Torvalds wrote:
On Tue, Feb 12, 2013 at 10:25 AM, H. Peter Anvin wrote:
I just thought up this variant, I'm about to test it, but H.J., do you
see any problems with it?
Looks good to me. And we already use __builtin_choose_expr(), so it's
"portable". And it shoul
On Tue, Feb 12, 2013 at 10:25 AM, H. Peter Anvin wrote:
> I just thought up this variant, I'm about to test it, but H.J., do you
> see any problems with it?
Looks good to me. And we already use __builtin_choose_expr(), so it's
"portable". And it should avoid all the potential issues with
bitfield
On Tue, Feb 12, 2013 at 10:25 AM, H. Peter Anvin wrote:
> I just thought up this variant, I'm about to test it, but H.J., do you
> see any problems with it?
>
> #define itype(x) \
> __typeof__(__builtin_choose_expr(sizeof(*(x)) > sizeof(0UL), 0ULL, 0UL))
>
> I tried it out with a small test progra
I just thought up this variant, I'm about to test it, but H.J., do you
see any problems with it?
#define itype(x) \
__typeof__(__builtin_choose_expr(sizeof(*(x)) > sizeof(0UL), 0ULL, 0UL))
I tried it out with a small test program (attached), and it seems to
work. Next for using it in the kernel.
On Tue, Feb 12, 2013 at 09:32:54AM -0800, Linus Torvalds wrote:
> On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
> >
> > No, I think what he is talking about it this bit:
>
> Ok, I agree that the bitfield code actually looks cleaner.
>
> That said, maybe gcc has an easier time using a fe
On Tue, Feb 12, 2013 at 9:35 AM, H. Peter Anvin wrote:
>
> On the other hand, it still uses two gcc extensions: long long bitfields and
> typeof.
>
> I'll see what kind of code we get with the macro.
At least one thing to look out for is the poor LLVM people who are
trying to make the kernel comp
On 02/12/2013 09:32 AM, Linus Torvalds wrote:
On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
No, I think what he is talking about it this bit:
Ok, I agree that the bitfield code actually looks cleaner.
That said, maybe gcc has an easier time using a few odd builtins and
magic typeof
On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
>
> No, I think what he is talking about it this bit:
Ok, I agree that the bitfield code actually looks cleaner.
That said, maybe gcc has an easier time using a few odd builtins and
magic typeof's. But at least the bitfield trick looks half-
On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
> On 02/12/2013 09:00 AM, Linus Torvalds wrote:
>> On Tue, Feb 12, 2013 at 8:38 AM, H.J. Lu wrote:
>>>
>>> Can you do something similar to what we did in glibc:
>>
>> No. Because we use macros to be type-independent (i e"get_user()"
>> works
On 02/12/2013 09:00 AM, Linus Torvalds wrote:
> On Tue, Feb 12, 2013 at 8:38 AM, H.J. Lu wrote:
>>
>> Can you do something similar to what we did in glibc:
>
> No. Because we use macros to be type-independent (i e"get_user()"
> works *regardless* of type), so casting to "uintptr_t" doesn't work.
On Tue, Feb 12, 2013 at 8:38 AM, H.J. Lu wrote:
>
> Can you do something similar to what we did in glibc:
No. Because we use macros to be type-independent (i e"get_user()"
works *regardless* of type), so casting to "uintptr_t" doesn't work.
It throws away the type information, and truncates 64-bi
On Mon, Feb 11, 2013 at 8:21 PM, H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
>> On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
>> wrote:
>>>
>>> However, we can declare a bitfield using sizeof(), which is legal
>>> because sizeof() is a constant expression.
* H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
> > On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
> > wrote:
> >>
> >> However, we can declare a bitfield using sizeof(), which is legal
> >> because sizeof() is a constant expression. This quiets the warning
Just to be sure, I re-ran the comparison using gcc 4.6.3 instead of gcc
4.7.2. With gcc 4.6.3 I consistently get a few hundred bytes longer
with the bitfield variant than with the pre-get_user() baseline.
I looked at some of the diffed disassembly, and the differences seem to
be in the code gener
On 02/11/2013 08:47 PM, Linus Torvalds wrote:
On Mon, Feb 11, 2013 at 8:42 PM, Linus Torvalds
wrote:
But I don't see anything fundamentally wrong with it. Certainly it
looks much better than the disgusting and warning-prone
unsigned long long __val_gu8
thing.
Oh. I just realized. That
On Mon, Feb 11, 2013 at 8:42 PM, Linus Torvalds
wrote:
>
> But I don't see anything fundamentally wrong with it. Certainly it
> looks much better than the disgusting and warning-prone
>
> unsigned long long __val_gu8
>
> thing.
Oh. I just realized. That was your _baseline_ in the comparisons,
On Mon, Feb 11, 2013 at 8:21 PM, H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
>
>> Has anybody run this past any gcc developers? And if so, did they run
>> away screaming?
>
> I haven't no... H.J., any comments on this patch?
I'd be most worried about any known pitfalls a
On 02/11/2013 07:33 PM, Linus Torvalds wrote:
> On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
> wrote:
>>
>> However, we can declare a bitfield using sizeof(), which is legal
>> because sizeof() is a constant expression. This quiets the warning,
>> although the code generated isn't
On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
wrote:
>
> However, we can declare a bitfield using sizeof(), which is legal
> because sizeof() is a constant expression. This quiets the warning,
> although the code generated isn't 100% identical from the baseline
> before 96477b4 x86-
Commit-ID: b390784dc1649f6e6c5e66e5f53c21e715ccf39b
Gitweb: http://git.kernel.org/tip/b390784dc1649f6e6c5e66e5f53c21e715ccf39b
Author: H. Peter Anvin
AuthorDate: Mon, 11 Feb 2013 16:27:28 -0800
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:26:51 -0800
x86, mm: Use a bitfiel
20 matches
Mail list logo
