From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Richard Henderson Cc: Tim Hollebeek , craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Sat, 05 Jun 1999 09:50:00 -0000 Message-id: References: <19990604152035.B18469@cygnus.com> X-SW-Source: 1999-06/msg00195.html On Fri, 4 Jun 1999, Richard Henderson wrote: > > This doesn't handle > > extern inline int foo(short *ptr) > { > return *ptr; > } > > int bar(void) > { > int i; > i = 0; > return foo((short *)&i); > } > > Which isn't unlike some uses of inlines in the kernel. Again - I _really_ didn't mean for this to be some Linux kernel specific hack. Think of it as a larger problem than just the kernel. Think of it as the problem of "we have a huge code-base, and it wasn't written with type-based alias in mind - and the new ANSI rules are fairly cumbersome, but we'd like to have access to the new optimization: not only is it the default, but it does generate better code too!". It's not that changes wouldn't be needed, it's the fact that the ANSI rules really only give you two ways to overcome the alias issue: - "char *" - which is just unbearably slow, and obviously not really an option for many things. You're better off just disabling the alias logic altogether. - using a union - which does work, but is just incredibly horrible syntax if you don't have just one well-defined case and/or designed with it in mind. For example, the union approach is obviously acceptable if you have the specific case of once in a blue moon (a few times in a large project) a need to convert floating point to the integer bit pattern representation and back. And that's obviously what ANSI was concerned with. The "cast invalidates alias information" is a _syntactical_ thing to do the same thing much more simply. I find it much more natural anyway, and as I tried to show it /should/ be straightforward to implement. Gcc has various of these ANSI extensions that are really purely syntactical: - "a ? : b" is just syntactical sugar for "a ? a : b" - pointer casting lvalues is syntactical sugar for something that is actually reasonably hard to do, but occasionally useful. In fact, think of it the same was as the casting of lvalues: sure, you CAN do it with standard ANSI C, but it cumbersome. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Richard Henderson Cc: Tim Hollebeek , craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: References: <19990604152035.B18469@cygnus.com> X-SW-Source: 1999-06n/msg00195.html Message-ID: <19990630154300.CbbBRCZ1bmtmUKSV81P0Y0sn6KaaRj95pzsBWKiff74@z> On Fri, 4 Jun 1999, Richard Henderson wrote: > > This doesn't handle > > extern inline int foo(short *ptr) > { > return *ptr; > } > > int bar(void) > { > int i; > i = 0; > return foo((short *)&i); > } > > Which isn't unlike some uses of inlines in the kernel. Again - I _really_ didn't mean for this to be some Linux kernel specific hack. Think of it as a larger problem than just the kernel. Think of it as the problem of "we have a huge code-base, and it wasn't written with type-based alias in mind - and the new ANSI rules are fairly cumbersome, but we'd like to have access to the new optimization: not only is it the default, but it does generate better code too!". It's not that changes wouldn't be needed, it's the fact that the ANSI rules really only give you two ways to overcome the alias issue: - "char *" - which is just unbearably slow, and obviously not really an option for many things. You're better off just disabling the alias logic altogether. - using a union - which does work, but is just incredibly horrible syntax if you don't have just one well-defined case and/or designed with it in mind. For example, the union approach is obviously acceptable if you have the specific case of once in a blue moon (a few times in a large project) a need to convert floating point to the integer bit pattern representation and back. And that's obviously what ANSI was concerned with. The "cast invalidates alias information" is a _syntactical_ thing to do the same thing much more simply. I find it much more natural anyway, and as I tried to show it /should/ be straightforward to implement. Gcc has various of these ANSI extensions that are really purely syntactical: - "a ? : b" is just syntactical sugar for "a ? a : b" - pointer casting lvalues is syntactical sugar for something that is actually reasonably hard to do, but occasionally useful. In fact, think of it the same was as the casting of lvalues: sure, you CAN do it with standard ANSI C, but it cumbersome. Linus