llvm dev - Jan 2020 - Global removal pass - potential for improvement?

Hey everyone,
I was looking into how the global optimization pass fares against things
like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676
Looking at this, I think it would be pretty trivial to optimize that down
given that there are already threading assumptions made:
https://godbolt.org/z/u6ZqoB
Is this something I can look into? Another thing is that currently *all*
external calls break this optimization, including calls to intrinsics that
probably shouldn't: https://godbolt.org/z/pK7Cew
Maybe add some sort of way (i.e. an attribute) to mark that a call can be
optimized through in this way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/074c97ea/attachment.html>

On Tue, Jan 28, 2020 at 8:09 PM Karl Rehm via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hey everyone,
> I was looking into how the global optimization pass fares against things
like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676
> Looking at this, I think it would be pretty trivial to optimize that down
given that there are already threading assumptions made:
https://godbolt.org/z/u6ZqoB
> Is this something I can look into?
> Another thing is that currently *all* external calls break this
optimization, including calls to intrinsics that probably shouldn't:
https://godbolt.org/z/pK7Cew
I think during load propagation, there is a legality check "here's a
load, and here's a store.
Is there anything in between that may have clobbered that memory
location?".
For calls, there are some attributes that are helpful here:
https://llvm.org/docs/LangRef.html#function-attributes
So in this case, i guess `@llvm.x86.flags.write` intrinsic maybe can
be annotated with readonly attribute,
thus signalling that it won't clobber that memory location?
> Maybe add some sort of way (i.e. an attribute) to mark that a call can be
optimized through in this way?
Roman
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Looks like I'm dumb, seems like this only happens with the one intrinsic I
chose which happens to not have the attribute (and probably can't have it
because of its behavior) :^)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/9f30c0f4/attachment.html>

Hi Karl, Roman,

On 01/28, Roman Lebedev via llvm-dev wrote:
> On Tue, Jan 28, 2020 at 8:09 PM Karl Rehm via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I was looking into how the global optimization pass fares against
> > things like what's reported in
> > https://bugs.llvm.org/show_bug.cgi?id=44676
I need to take a closer look but I would have expected BasicAA to be
able to determine that `do_log` and `R` cannot alias. In the -Os version
(lower right here https://gcc.godbolt.org/z/KLaeiH), the write to `R`
clobbers the read from `do_log` which prevents us from removing the
load/store pair. My reasoning would have been that we know the size of
`do_log` to be less than the size accessed via `R`. What exactly goes
wrong or if my logic is flawed needs to be examined. I would start
looking at the debug generated by the code parts touched here:
https://reviews.llvm.org/D66157

> > Looking at this, I think it would be pretty trivial to optimize that
> > down given that there are already threading assumptions made:
> > https://godbolt.org/z/u6ZqoB
Optimizing more aggressively based on forward process guarantees will
get us in more trouble than we are already in. I don't have the link
handy but as far as I remember the proposed solution was to have a
forward process guarantee function attribute. I would recommend we look
into that first before we start more aggressive optimizations which will
cause problems for a lot of (non C/C++) folks.

> > Is this something I can look into?
Sure :)

> > Another thing is that currently *all* external calls break this
> > optimization, including calls to intrinsics that probably
shouldn't:
> > https://godbolt.org/z/pK7Cew
> I think during load propagation, there is a legality check "here's
a
> load, and here's a store.
> Is there anything in between that may have clobbered that memory
location?".
Right now we only have `__attribute__((pure/const))` but we want to
expose all LLVM-IR attributes to the user soon [0] which will allow way
more fine-grained control. Intrinsics are a different story again.

> For calls, there are some attributes that are helpful here:
> https://llvm.org/docs/LangRef.html#function-attributes
> So in this case, i guess `@llvm.x86.flags.write` intrinsic maybe can
> be annotated with readonly attribute,
> thus signalling that it won't clobber that memory location?
While target specific intrinsics are a bit more complicated we see the
problem often with generic intrinsic already. We proposed the other day
[1] to change the default semantics of non-target specific intrinsics
such that you have to opt-in for certain effects.

For the above example you want `llvm.x86.flags.write` to be `writeonly` and
`inaccesiblememonly`. Also `nosync`, `willreturn`, ...

Cheers,
  Johannes


[0] https://www.youtube.com/watch?v=elmio6AoyK0
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-August/134404.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/e867acde/attachment.sig>