Re: gcc feature request / RFC: extra clobbered regs
On 06/30/2015 04:02 PM, H. Peter Anvin wrote:
On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin wrote:
On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
I'd say the most natural API for this would be to allow
f{fixed,call-{used,saved}}-REG in target attribute.
Either that or
__attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
... just to be shorter. Either way, I would consider this to be
desirable -- I have myself used this to good effect in a past life
(*cough* Transmeta *cough*) -- but not a high priority feature.
I think I mean the per-function equivalent of -fcall-used-reg, so
hpa's "used" suggestion would do the trick.
I guess that clobbering the frame pointer is a non-starter, but five
out of six isn't so bad. It would be nice to error out instead of
producing "disastrous results", though, if another bad reg is chosen.
(Presumably the PIC register on PIC builds would be an example of
that.)
Clobbering the frame pointer is perfectly fine, as is the PIC register.
However, gcc might need to handle them as "fixed" rather than "clobbered".
Hmm. True, I guess, although I wouldn't necessarily expect gcc to be
able to generate code to call a function like that.
No, but you need to be able to call other functions, or you just push
the issue down one level.
For ia32, the PIC register really isn't special anymore. I'd be
surprised if you couldn't clobber it.
jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: gcc feature request / RFC: extra clobbered regs
On 06/30/2015 04:02 PM, H. Peter Anvin wrote:
On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
I'd say the most natural API for this would be to allow
f{fixed,call-{used,saved}}-REG in target attribute.
Either that or
__attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
... just to be shorter. Either way, I would consider this to be
desirable -- I have myself used this to good effect in a past life
(*cough* Transmeta *cough*) -- but not a high priority feature.
I think I mean the per-function equivalent of -fcall-used-reg, so
hpa's used suggestion would do the trick.
I guess that clobbering the frame pointer is a non-starter, but five
out of six isn't so bad. It would be nice to error out instead of
producing disastrous results, though, if another bad reg is chosen.
(Presumably the PIC register on PIC builds would be an example of
that.)
Clobbering the frame pointer is perfectly fine, as is the PIC register.
However, gcc might need to handle them as fixed rather than clobbered.
Hmm. True, I guess, although I wouldn't necessarily expect gcc to be
able to generate code to call a function like that.
No, but you need to be able to call other functions, or you just push
the issue down one level.
For ia32, the PIC register really isn't special anymore. I'd be
surprised if you couldn't clobber it.
jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On 02/25/14 17:15, Paul E. McKenney wrote: I have for the last several years been 100% convinced that the Intel memory ordering is the right thing, and that people who like weak memory ordering are wrong and should try to avoid reproducing if at all possible. But given that we have memory orderings like power and ARM, I don't actually see a sane way to get a good strong ordering. You can teach compilers about cases like the above when they actually see all the code and they could poison the value chain etc. But it would be fairly painful, and once you cross object files (or even just functions in the same compilation unit, for that matter), it goes from painful to just "ridiculously not worth it". And I have indeed seen a post or two from you favoring stronger memory ordering over the past few years. ;-) I couldn't agree more. Are ARM and Power really the bad boys here? Or are they instead playing the role of the canary in the coal mine? That's a question I've been struggling with recently as well. I suspect they (arm, power) are going to be the outliers rather than the canary. While the weaker model may give them some advantages WRT scalability, I don't think it'll ultimately be enough to overcome the difficulty in writing correct low level code for them. Regardless, they're here and we have to deal with them. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On 02/25/14 17:15, Paul E. McKenney wrote: I have for the last several years been 100% convinced that the Intel memory ordering is the right thing, and that people who like weak memory ordering are wrong and should try to avoid reproducing if at all possible. But given that we have memory orderings like power and ARM, I don't actually see a sane way to get a good strong ordering. You can teach compilers about cases like the above when they actually see all the code and they could poison the value chain etc. But it would be fairly painful, and once you cross object files (or even just functions in the same compilation unit, for that matter), it goes from painful to just ridiculously not worth it. And I have indeed seen a post or two from you favoring stronger memory ordering over the past few years. ;-) I couldn't agree more. Are ARM and Power really the bad boys here? Or are they instead playing the role of the canary in the coal mine? That's a question I've been struggling with recently as well. I suspect they (arm, power) are going to be the outliers rather than the canary. While the weaker model may give them some advantages WRT scalability, I don't think it'll ultimately be enough to overcome the difficulty in writing correct low level code for them. Regardless, they're here and we have to deal with them. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:43, Linus Torvalds wrote:
I think we should likely keep __FD_SETSIZE, since that really is a
valid kernel value (that the kernel actually uses). The rest looks
*entirely* bogus.
I can certainly live with that.
Josh, looks like you've got marching orders :-)
Of course there'll be some kind of fallout, there always is.
And the reason I emphasize the "entirely" is literally that the kernel
headers don't even define the full __FD_SET/CLR/ISSET() functionality.
I know. When this first came to my attention I feared I'd find another
implementation of FD_{SET,CLR}/ISSET.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:24, Linus Torvalds wrote:
On Tue, Jul 24, 2012 at 12:15 PM, Jeff Law wrote:
Please refer to the original discussion where they did evaluate the cost of
this change and tested that the final change made no difference to the
generated code.
Umm. That bugzilla entry seems to be talking about a *sane* change, namely
- ({ unsigned long int __d = (d); \
+ ({ unsigned long int __d = (unsigned long int) (d); \
in __FD_ELT(), which is totally different from the one Josh talks about.
Right. Josh's change is necessary to prevent warnings from folks
(incorrectly) using posix_types.h instead of select.h after the change
in that BZ was made. That's why I originally stated that, arguably,
posix_types.h really should go away or just use the definitions provided
by glibc.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] posix_types.h: make __NFDBITS match glibc definition
On 07/24/12 12:24, Josh Boyer wrote: On Tue, Jul 24, 2012 at 11:20:11AM -0700, Linus Torvalds wrote: On Tue, Jul 24, 2012 at 11:12 AM, Josh Boyer wrote: +#define __NFDBITS (8 * (int) sizeof(long int)) I don't know if the type change is needed, but who the hell uses "long int"? Not strictly, no. I believe in my brief tests, just the int cast was sufficient. I can respin if you'd like. I probably need to anyway to CC stable on this. All that's strictly necessary is that cast to (int). That avoids the problem. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:09, Linus Torvalds wrote: On Tue, Jul 24, 2012 at 12:03 PM, Josh Boyer wrote: FWIW, the definitions of __FD_ELT/__FD_MASK in glibc are: #define __FD_ELT(d) ((d) / __NFDBITS) #define __FD_MASK(d)((__fd_mask) 1 << ((d) % __NFDBITS)) where __fd_mask is 'typdef long int'. Yeah, that's not good. If __NFDBITS is signed (and it is), and "d" is a signed type, that division and modulus now create stupid extra code with conditionals (assuming 'd' isn't constant, of course). So changing the sign of __NFDBITS has these kinds of subtle side effects that clearly the glibc people didn't actually think about. What was the *advantage* of that stupidity? Quite frankly, if you want to make NFDBITS be an "int", then it should have been done at that #define NFDBITS ((int)__NFDBITS) level, not at "__NFDBITS". Exactly because the unsigned type there matters. Does anybody in the glibc camp care about efficient and small code AT ALL? Please refer to the original discussion where they did evaluate the cost of this change and tested that the final change made no difference to the generated code. http://sourceware.org/bugzilla/show_bug.cgi?id=14210 Needlessly slamming these folks doesn't help anything. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:09, Linus Torvalds wrote: On Tue, Jul 24, 2012 at 12:03 PM, Josh Boyer jwbo...@redhat.com wrote: FWIW, the definitions of __FD_ELT/__FD_MASK in glibc are: #define __FD_ELT(d) ((d) / __NFDBITS) #define __FD_MASK(d)((__fd_mask) 1 ((d) % __NFDBITS)) where __fd_mask is 'typdef long int'. Yeah, that's not good. If __NFDBITS is signed (and it is), and d is a signed type, that division and modulus now create stupid extra code with conditionals (assuming 'd' isn't constant, of course). So changing the sign of __NFDBITS has these kinds of subtle side effects that clearly the glibc people didn't actually think about. What was the *advantage* of that stupidity? Quite frankly, if you want to make NFDBITS be an int, then it should have been done at that #define NFDBITS ((int)__NFDBITS) level, not at __NFDBITS. Exactly because the unsigned type there matters. Does anybody in the glibc camp care about efficient and small code AT ALL? Please refer to the original discussion where they did evaluate the cost of this change and tested that the final change made no difference to the generated code. http://sourceware.org/bugzilla/show_bug.cgi?id=14210 Needlessly slamming these folks doesn't help anything. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] posix_types.h: make __NFDBITS match glibc definition
On 07/24/12 12:24, Josh Boyer wrote: On Tue, Jul 24, 2012 at 11:20:11AM -0700, Linus Torvalds wrote: On Tue, Jul 24, 2012 at 11:12 AM, Josh Boyer jwbo...@redhat.com wrote: +#define __NFDBITS (8 * (int) sizeof(long int)) I don't know if the type change is needed, but who the hell uses long int? Not strictly, no. I believe in my brief tests, just the int cast was sufficient. I can respin if you'd like. I probably need to anyway to CC stable on this. All that's strictly necessary is that cast to (int). That avoids the problem. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:24, Linus Torvalds wrote:
On Tue, Jul 24, 2012 at 12:15 PM, Jeff Law l...@redhat.com wrote:
Please refer to the original discussion where they did evaluate the cost of
this change and tested that the final change made no difference to the
generated code.
Umm. That bugzilla entry seems to be talking about a *sane* change, namely
- ({ unsigned long int __d = (d); \
+ ({ unsigned long int __d = (unsigned long int) (d); \
in __FD_ELT(), which is totally different from the one Josh talks about.
Right. Josh's change is necessary to prevent warnings from folks
(incorrectly) using posix_types.h instead of select.h after the change
in that BZ was made. That's why I originally stated that, arguably,
posix_types.h really should go away or just use the definitions provided
by glibc.
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] posix_types.h: make __NFDBITS compatible with glibc definition
On 07/24/12 13:43, Linus Torvalds wrote:
I think we should likely keep __FD_SETSIZE, since that really is a
valid kernel value (that the kernel actually uses). The rest looks
*entirely* bogus.
I can certainly live with that.
Josh, looks like you've got marching orders :-)
Of course there'll be some kind of fallout, there always is.
And the reason I emphasize the entirely is literally that the kernel
headers don't even define the full __FD_SET/CLR/ISSET() functionality.
I know. When this first came to my attention I feared I'd find another
implementation of FD_{SET,CLR}/ISSET.
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
