[Bug c++/38253] [4.4 regression] g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc

jakub at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Wed Dec 10 13:14:00 GMT 2008



------- Comment #5 from jakub at gcc dot gnu dot org  2008-12-10 13:13 -------
I guess the primary difference between e.g. x86_64 or i386 and powerpc is
during gimplification, the pointer-to-member initialization is done as:
    D.1804.__pfn = funcOne;
    D.1804.__delta = 0;
    i.1 = docalling (D.1804);
on i386/x86_64, but as:
  static struct 
{
  String:: * __pfn;
  long int __delta;
} C.1 = {.__pfn=funcOne, .__delta=0};
...
    D.1807 = C.1;
    i.2 = docalling (D.1807);

and later on esra even makes it harder to find out what the function is.

This is gimplify_init_constructor, where:
if (size > 0 && !can_move_by_pieces (size, align))
(for -m64 with size 16, align 64, for -m32 with size 8, align 32)
on powerpc is true and so a temporary is created, on i386/x86_64
can_move_by_pieces returns 1 because MOVE_RATIO is larger and so it is
initialized piece-wise.

In this case (2 integral field ctor, one entry is 0, one is an address) I doubt
it makes sense on any arch to do the temporary (if that would be true, then
just the constant should be forced into memory by mov[sd]i expander).
can_move_by_pieces doesn't make much sense either, we are deciding whether to
initialize piece-wise or not, for piece-wise initialization we want to see if
storing the constants into memory isn't too expensive (so more like
can_store_by_pieces with appropriate callback).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253



More information about the Gcc-bugs mailing list