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

[Sergei Larin via llvm-commits]

slarin added a comment.

Hi Rafael,

> 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.


Can you give an overview of what you are using the section for?

Cheers,
Rafael

We have to perform LTO on embedded project with hard section assignment. Part of this assignment is driven by pragmas in customer code. GlobalOPT is rather profitable for the kind of code we optimize.

Nevertheless, this change in its own right is independent from our final goal. The point of this patch is that LLVM IR semantics are not preserved by GlobalOPT for no good reason even _outside_ of LTO context... In all of the introduced tests I take legal LLVM IR and use a basic compiler transformation on it with the net result of loss of some IR attributes... ...and the fix is trivial!

If you are conceptually OK with this fix, I will update MallocSROA-section.ll and do the cosmetic changes Mehdi requested in the next patch.


================
Comment at: test/Transforms/GlobalOpt/GSROA-section.ll:6
@@ +5,3 @@
+; RUN: opt < %s -globalopt -S | FileCheck %s
+; Check that the new global values still have their address space
+; CHECK: @struct
----------------
rafael wrote:
> You are checking the section, not the address space.
Yes, this is the intent. Without this patch "struct" uses its original section assignment.


http://reviews.llvm.org/D16074