Using MSVC with /Ox (Full Optimization) all three generate the same code:
push OFFSET _s
call _bar
pop ecx
/Søren
On Mon, Sep 29, 2008 at 10:25 PM, Erik Corry <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---