I took a look at what code gcc-4.0 generates for these two ways of doing things. I defined a function called bar that takes an Object** and three functions (called use_reinterpret_cast, use_union and use_bit_cast) that take the address of a String*, cast it to an Object** and call bar. The source code is attached.
I compiled with -O3 -fomit-frame-pointer -m32
use_union and use_reinterpret_cast compile down to:
subl $12, %esp
movl $s, (%esp)
call bar
addl $12, %esp
ret
use_bit_cast compiles to:
subl $28, %esp
movl $s, 24(%esp)
movl $s, 20(%esp)
movl $s, (%esp)
call bar
addl $28, %esp
ret
A clear win for the union method.
However on gcc 4.2 they all three compile down to the short version,
and the reinterpret_cast version gives a warning about type punning.
gcc-4.2 is standard in Ubuntu Hardy so it is not exotic.
I wonder what the result is for MSVC?
Whether we use the union method or the bit_cast method we are really
just obfuscating things in order to avoid the warning from gcc caused
by casting one pointer to another pointer. The bit_cast and union
methods only really work for simple types, not for pointers. I guess
we should be happy that the code generator can deobfuscate the code
while the warning generator remains confused...
Given this, perhaps we should just disable that warning from gcc. On
the other hand it might in future catch a real problem.
I am tending towards doing the change with bit_cast since it is less
intrusive in terms of nonlocal changes to the code. We should
recognize that it is not a panacea, and if we introduce it in other
places to get rid of type punning warnings we need to ensure that
there is not a type punning problem first! Otherwise we might just as
well disable the warning.
On Thu, Sep 25, 2008 at 6:16 PM, <[EMAIL PROTECTED]> wrote:
>
> Issue 94: Get rid of -fnostrict-aliasing
> http://code.google.com/p/v8/issues/detail?id=94
>
> Comment #1 by [EMAIL PROTECTED]:
> When I looked there was 2 cases of this, one which seems like it could be
> handled
> with a bit_cast<>, maybe v8 should just steal this from Chromium's
> basictypes.h?
>
> http://repo.or.cz/w/chromium.git?
> a=blob;f=src/base/basictypes.h;h=36156e43c8e38b9703d23cafacb370a83dea4c0b;hb=trunk
>
>
>
>
>
> --
> You received this message because you are listed in the owner
> or CC fields of this issue, or because you starred this issue.
> You may adjust your issue notification preferences at:
> http://code.google.com/hosting/settings
>
> >
>
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---
comparison.cc
Description: Binary data
