This is an archive of the discontinued LLVM Phabricator instance.

Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.
ClosedPublic

Authored by slarin on Jan 11 2016, 11:31 AM.

Details

Summary

Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.

A good example of improper behavior in the current implementation is section information associated with the GlobalObject. If a section was set for it, and GlobalOpt is creating/modifying a new object based on this one (often copying the original name), without this change new object will be placed in a default section, resulting in inappropriate properties of the new variable.
The argument here is that if customer specified a section for a variable, any changes to it that compiler does should not cause it to change that section allocation.
Moreover, any other properties worth representation in copyAttributesFrom() should also be propagated.

Diff Detail

Event Timeline

slarin updated this revision to Diff 44529.Jan 11 2016, 11:31 AM
slarin retitled this revision from to Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object..
slarin updated this object.
slarin added a subscriber: llvm-commits.
mehdi_amini added a subscriber: mehdi_amini.

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?

lib/Transforms/IPO/GlobalOpt.cpp
504

Nit: moving it one line above seems nicer to me.

539

same

slarin added a subscriber: slarin.Jan 11 2016, 12:12 PM

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.

I know that global opt is not conservative enough, but I thought the conservative fix was to update any pass that "optimize" with variable with section and prevent it to do so, i.e. I had in mind what Chris wrote here: http://lists.llvm.org/pipermail/llvm-dev/2015-September/090587.html
(Note: I'm not opposed to this, I'm just not knowledgeable enough about what can go wrong)

Yes, We had this discussion with Chris (see more context here)

http://lists.llvm.org/pipermail/llvm-dev/2015-September/090923.html

...but I read his final comment as a comment, not as a hard suggestion... Partially for that reason I propose something that looks for me as a simpler solution, but you are right, I really want to make sure enough opinions are expressed.

In your current universe - will this change cause any issues? Will it matter at all? Would it help anything?

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

The most common uses cases for explicit sections I'm aware of here are situations where the user wants to place part of the code into special memory (e.g. tightly-coupled memory). You're free to optimize within that special section - in fact, that's even desired because the code tends to be very performance-critical (but space-constrained) - but introducing additional control or data edges to other sections is a no-go (which is what we're currently doing in GlobalOpt). The proposed patch would solve the problem nicely.

This is probably OK with the nits addressed since it doesn't introduce new optimizations, just makes existing ones a bit less objectionable.

test/Transforms/GlobalOpt/GSROA-section.ll
7

You are checking the section, not the address space.

test/Transforms/GlobalOpt/MallocSROA-section.ll
11

You can probably clean up this test. You don't need the numf2s global, init_net can just take an argument to store, you don't need the nounwind marker, etc.

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.

test/Transforms/GlobalOpt/GSROA-section.ll
7

Yes, this is the intent. Without this patch "struct" uses its original section assignment.

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.

Sure.

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.

But then the comment is out of sync.

slarin updated this revision to Diff 45408.Jan 20 2016, 10:21 AM

Implemented suggested changes.

Simplified, but could not fully change MallocSROA-section.ll since for global OPT to trigger properly and not to optimize out the whole test, both local and global objects seem to be needed.

This is fine by me, but give Mehdi a chance to comment too.

test/Transforms/GlobalOpt/GSROA-section.ll
12

Please drop the addresspace or check it.

slarin updated this revision to Diff 45435.Jan 20 2016, 1:03 PM

Cleared addrspace in tests.

mehdi_amini accepted this revision.Jan 22 2016, 1:15 PM
mehdi_amini added a reviewer: mehdi_amini.

Sorry I missed Rafael comment.
LGTM.

This revision is now accepted and ready to land.Jan 22 2016, 1:15 PM
slarin closed this revision.Jan 22 2016, 1:22 PM