Chris, sorry for the delay with the response...
I deal with code that uses a linker scripts and explicitly set section
attributes in the source (embedded environment) so most globals are firmly
assigned to output sections. Preventing transformations on them is
counterproductive, but in each case a new (copy, or modification) of the
original GV is created, it needs to go to the same output section as did the
original. It is even more important when something like this is assumed:
// Retain the name of the old global variable. People who are debugging their
// programs may expect these variables to be named the same.
NewGV->takeName(GV);
GV->eraseFromParent();
IR is sufficient for most simple cases when GlobalObject carries section
assignment. I can always infer section being touched when dealing with any uses
of it.
What IR is not designed to do is LTO in presence of a linker script, but this is
another can of worms and we can discuss it in person at the dev meeting.
Meanwhile the remedy is trivial - just copy attributes from GV to NewGV every
time NewGV can be explicitly present/used after the transformation - it will
have no effect on cases when there is no section is set, and will allow some
poor souls optimize embedded code a bit better :)
Sergei
P.S. Here is an example:
; RUN: opt < %s -S -globalopt -instcombine | FileCheck %s
;; check that global opt turns integers into bools and keeps section info.
@G = internal addrspace(1) global i32 0, section ".foo"
; CHECK: @G
; CHECK: addrspace(1)
; CHECK: global i1 false
; CHECK: section ".foo"
define void @set1() {
store i32 0, i32 addrspace(1)* @G
; CHECK: store i1 false
ret void
}
define void @set2() {
store i32 1, i32 addrspace(1)* @G
; CHECK: store i1 true
ret void
}
define i1 @get() {
; CHECK-LABEL: @get(
%A = load i32, i32 addrspace(1) * @G
%C = icmp slt i32 %A, 2
ret i1 %C
; CHECK: ret i1 true
}
---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation
> -----Original Message-----
> From: Chris Lattner [mailto:clattner at apple.com]
> Sent: Monday, September 21, 2015 10:37 PM
> To: Sergei Larin
> Cc: llvm-dev at lists.llvm.org; Lang Hames
> Subject: Re: GlobalOPT and sections
>
> On Sep 21, 2015, at 11:59 AM, Sergei Larin <slarin at codeaurora.org>
wrote:
> > Chris,
> >
> > Thanks for the clarification... at least no bug report is due... and
I am glad
> that I've asked.
> >
> > In my case these transformations are rather useful and forcing them to
> copy original global variable section is making them compatible with our
> (rather important) use case, so I guess I will have to fix it locally.
> > Nevertheless if someone else would have a similar issue - I would be
happy
> to patch it.
>
> Ah, so you’re saying that you *want* the transformation, but the global has
> an explicit section?
>
> Two questions:
> 1) Why does the global have a section? Is this something that should be
> better modeled in IR somehow?
> 2) Perhaps this transformation can be better modeled as something that
> uses IPA to inject “range” metadata on loads from globals?
>
> Doing #2 would allow inferring that a global only has something in the
range
> of 0..5, at least when the only stores are simple enough to analyze
trivially.
>
> -Chris
>
>
> >
> > Sergei
> >
> > ---
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > hosted by The Linux Foundation
> >
> >
> >> -----Original Message-----
> >> From: Chris Lattner [mailto:clattner at apple.com]
> >> Sent: Sunday, September 20, 2015 5:28 PM
> >> To: Sergei Larin
> >> Cc: llvm-dev at lists.llvm.org; Lang Hames
> >> Subject: Re: GlobalOPT and sections
> >>
> >> On Sep 18, 2015, at 10:45 AM, Sergei Larin <slarin at
codeaurora.org>
> wrote:
> >>> What I do not see - the section information from the original
GV is
> >>> never
> >> copied to the NewGV, so this test would be failing for me:
> >>> Now the proverbial question - is this a bug or a feature?
...and if
> >>> it was
> >> meant to be done that way then why…
> >>
> >> Historically speaking, this optimization probably predated the
> >> ability to put a section on a global.
> >>
> >> That said, I think that this is a feature: The sorts of
optimizations
> >> that globalopt does are extremely transformative to the underlying
> >> global variable, and whatever reason the global was assigned to a
> >> section in the first place is probably not going to work with the
> transformed value.
> >>
> >> If you’re having a problem with this, it is probably best to just
> >> make globalopt more conservative: have it refuse to transform a
> >> global that has any explicitly assigned section.
> >>
> >> -Chris
> >