Rob Lyerly via llvm-dev
2017-Jun-30 16:24 UTC
[llvm-dev] Optimization Barrier in LLVM Backends
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>