[PATCH] D16074: Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.

[Larin, Sergei via llvm-commits]

Not really. See the test case - even if we mix GV with and without sections they will all be processed.

...but I think my point is slightly different - I cannot afford _not_ to do GlobalOpt - it is rather profitable for my use case. We have been using proposed fix in our codebase for a very long time now and I am pretty confident in this use scenario. The big question - is there anyone out there who assumes otherwise...? I see no .lit tests for the contrary, so I assume not.

> -----Original Message-----
> From: Mehdi AMINI [mailto:mehdi.amini at apple.com]
> Sent: Monday, January 11, 2016 1:56 PM
> To: Larin, Sergei; james.molloy at arm.com; mehdi_amini at apple.com
> Cc: mehdi.amini at apple.com; rafael.espindola at gmail.com;
> tobias at codeaurora.org; llvm-commits at lists.llvm.org
> Subject: Re: [PATCH] D16074: Make sure that any new and optimized objects
> created during GlobalOPT copy all the attributes from the base object.
> 
> joker.eph added a subscriber: joker.eph.
> joker.eph added a comment.
> 
> I thought we were conservatively avoiding to mess around with variable that
> have a section (address space?) attached. How do we know that we can split
> an array or a structure that has a section attached? Couldn't is be mapped to
> some hardware?
> 
> 
> ================
> Comment at: lib/Transforms/IPO/GlobalOpt.cpp:503
> @@ -502,2 +502,3 @@
>        Globals.push_back(NGV);
> +      NGV->copyAttributesFrom(GV);
>        NewGlobals.push_back(NGV);
> ----------------
> Nit: moving it one line above seems nicer to me.
> 
> ================
> Comment at: lib/Transforms/IPO/GlobalOpt.cpp:538
> @@ -536,2 +537,3 @@
>        Globals.push_back(NGV);
> +      NGV->copyAttributesFrom(GV);
>        NewGlobals.push_back(NGV);
> ----------------
> same
> 
> 
> http://reviews.llvm.org/D16074
> 
>