[llvm-dev] Optimization Barrier in LLVM Backends

[Rob Lyerly via llvm-dev]

Hi Ben,

I'm interested in disabling *all* optimizations across a given machine
instruction, not just load/store movement.  Basically I'm hoping to limit
the scope of optimizations so that at certain points in the application
code, the execution state (i.e., registers & stack) can be directly mapped
between architecture-specific layouts.  Additionally, by putting boundaries
around optimizations we can ensure that computation has reached a
semantically equivalent point.  Optimizations which create
architecture-specific live values or which perform code movement make it
much harder to find these "equivalence points".  If there was a way to put
boundaries around instructions, we could programmatically create
equivalence points.

I realize that hard boundaries like I'm describing may be too strong of a
requirement, so I think I can work around optimizations which create live
values known at compile-time, i.e., references to global values/stack
objects or immediates.  Just as a little more context, I'm using
LLVM's stackmap
intrinsic <http://llvm.org/docs/StackMaps.html> to capture live value
locations.  The stackmap already restricts memory movement around the
intrinsic's location.

Thanks!

On Thu, Jun 29, 2017 at 12:55 PM, Ben Craig <ben.craig at ni.com> wrote:

> It depends on what kinds of optimizations you want to turn off.  An easy
> (and heavy weight) thing to do to prevent memory optimizations from
> crossing a boundary is to insert sequentially consistent memory barriers.
> However, if the optimizer has determined that a given values address hasn’t
> escaped to another thread, then operations on that value won’t qualify as a
> memory operation, and it will still be able to travel across the memory
> barrier.
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Rob
> Lyerly via llvm-dev
> *Sent:* Thursday, June 29, 2017 11:09 AM
> *To:* Rob Lyerly via llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Optimization Barrier in LLVM Backends
>
>
>
> Hello,
>
> Is it possible to prevent optimizations across a given machine
> instruction, i.e., some sort of "optimization barrier", when doing
> architecture-specific optimizations during code generation?  For example,
> I'd like to be able to insert some form of instrumentation prevent an
> optimization pass from lifting a common sub-expression across a given
> machine instruction.
>
> I'm interested in capturing and maintaining an equivalent set of live
> values across compilations for different architectures, similarly to what
> is expressed in "A Unified Model of Pointwise Equivalence of Procedural
> Computations" (http://dl.acm.org/citation.cfm?id=197402).
> Architecture-specific optimizations very often create architecture-specific
> live values, which makes it hard to map live values between different
> architectures.
>
>
>
> Thanks for any help!
>
>
> --
>
> Rob Lyerly
>
> Graduate Research Assistant, Systems Software Research Group
>
> [image: Image removed by sender.] [image: Image removed by sender.]  [image:
> Image removed by sender.]
>



-- 
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170630/2bb048eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 392 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170630/2bb048eb/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 692 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170630/2bb048eb/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 338 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170630/2bb048eb/attachment-0002.jpg>