llvm dev - Aug 2016 - TryToShrinkGlobalToBoolean in GlobalOpt.cpp issue

Given some code:

static int x = 100;

int main() {
   x = 101;
   printf("%d\n", x);
}

results in:

%0 = load i1
%1 = select %0, 101, 100
...
...

1) What architecture(s) does this benefit?
2) What's the best way to circumvent this in the backend (currently I am
just not allowing this opt function to run)? I have tried a few
setOperationAction methods to no result. Rather not just comment out core
code because it makes porting more difficult.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160830/252e598a/attachment.html>

On Aug 30, 2016, at 1:01 PM, Ryan Taylor via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Given some code:
> 
> static int x = 100;
> 
> int main() {
>    x = 101;
>    printf("%d\n", x);
> }
> 
> results in:
> 
> %0 = load i1
> %1 = select %0, 101, 100
> ...
> ...
> 
> 1) What architecture(s) does this benefit?
Probably none of them.

The intent of this (very very old) optimization is to expose more value
information to the mid-level optimizer, which enables secondary simplification. 
If this simplification doesn’t happen, then this is probably almost always a
loss.

A better way to handle this is for GlobalOpt.cpp to tag the loads with the “new”
range metadata: http://llvm.org/docs/LangRef.html#range-metadata

In addition to this not pessimizing code, this would allow the analysis to be
more general: instead of identifying 1 or 2 constants, it could be generalized
to N ranges.

-Chris

Thanks Chris.

-Ryan

On Tue, Aug 30, 2016 at 5:19 PM, Chris Lattner <clattner at apple.com>
wrote:
> On Aug 30, 2016, at 1:01 PM, Ryan Taylor via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Given some code:
> >
> > static int x = 100;
> >
> > int main() {
> >    x = 101;
> >    printf("%d\n", x);
> > }
> >
> > results in:
> >
> > %0 = load i1
> > %1 = select %0, 101, 100
> > ...
> > ...
> >
> > 1) What architecture(s) does this benefit?
>
> Probably none of them.
>
> The intent of this (very very old) optimization is to expose more value
> information to the mid-level optimizer, which enables secondary
> simplification.  If this simplification doesn’t happen, then this is
> probably almost always a loss.
>
> A better way to handle this is for GlobalOpt.cpp to tag the loads with the
> “new” range metadata: http://llvm.org/docs/LangRef.html#range-metadata
>
> In addition to this not pessimizing code, this would allow the analysis to
> be more general: instead of identifying 1 or 2 constants, it could be
> generalized to N ranges.
>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160830/107efa5f/attachment.html>

> On Aug 30, 2016, at 1:01 PM, Ryan Taylor via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Given some code:
> 
> static int x = 100;
> 
> int main() {
>    x = 101;
>    printf("%d\n", x);
> }
> 
> results in:
> 
> %0 = load i1
> %1 = select %0, 101, 100
If x is only touched in one function, I’d expect globlaopt to turn it into an
alloca instead of leaving it global and shrinking it.
Did you oversimplify the real case where you see this for the sake of the
example here?

— 
Mehdi

> ...
> ...
> 
> 1) What architecture(s) does this benefit?
> 2) What's the best way to circumvent this in the backend (currently I
am just not allowing this opt function to run)? I have tried a few
setOperationAction methods to no result. Rather not just comment out core code
because it makes porting more difficult.
> 
> -Ryan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Yes, the full test case is:

static int x = 100;
int y = whatever;

int main() {
   x = -101;
   y = whatever that's not whatever above;
   printf("%d\n", y);
   printf("%d\n", x);
  return 0;
}

You are correct, in the above test case the globalopt does not make the
transformation.... however, I think the original issue still stands, it
really shouldn't be doing it here either.

On Tue, Aug 30, 2016 at 5:52 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> > On Aug 30, 2016, at 1:01 PM, Ryan Taylor via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Given some code:
> >
> > static int x = 100;
> >
> > int main() {
> >    x = 101;
> >    printf("%d\n", x);
> > }
> >
> > results in:
> >
> > %0 = load i1
> > %1 = select %0, 101, 100
>
> If x is only touched in one function, I’d expect globlaopt to turn it into
> an alloca instead of leaving it global and shrinking it.
> Did you oversimplify the real case where you see this for the sake of the
> example here?
>
> —
> Mehdi
>
>
> > ...
> > ...
> >
> > 1) What architecture(s) does this benefit?
> > 2) What's the best way to circumvent this in the backend
(currently I am
> just not allowing this opt function to run)? I have tried a few
> setOperationAction methods to no result. Rather not just comment out core
> code because it makes porting more difficult.
> >
> > -Ryan
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160830/71ee3ffd/attachment.html>