[llvm-dev] Optimization Barrier in LLVM Backends

[Rob Lyerly via llvm-dev]

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

  

[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 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....@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.

 

 

Thanks for any help!

--