search for: pr5680

I'm looking to tackle PR5680 [1]. The primary goal is to prevent behaviour changes in passes that depend on the order of use lists when serializing/deserializing the IR to a bitcode file (.bc) between passes. Here's a quick high-level summary: - When writing bitcode, calculate what the use list order will be after...

...t; > > >> On 2014-Jul-08, at 16:48, Chandler Carruth <chandlerc at google.com> > wrote: > >> > >> > >>> On Tue, Jul 8, 2014 at 4:29 PM, Duncan P. N. Exon Smith < > duncan at exonsmith.com> wrote: > >>> I'm looking to tackle PR5680 [1]. The primary goal is to prevent > >>> behaviour changes in passes that depend on the order of use lists when > >>> serializing/deserializing the IR to a bitcode file (.bc) between > passes. > >>> > >>> Here's a quick high-level summary: &g...

> On 2014-Jul-08, at 16:48, Chandler Carruth <chandlerc at google.com> wrote: > > >> On Tue, Jul 8, 2014 at 4:29 PM, Duncan P. N. Exon Smith <duncan at exonsmith.com> wrote: >> I'm looking to tackle PR5680 [1]. The primary goal is to prevent >> behaviour changes in passes that depend on the order of use lists when >> serializing/deserializing the IR to a bitcode file (.bc) between passes. >> >> Here's a quick high-level summary: >> >> - When writing bitcod...

...ne (compared to "run the compiler twice on the same input and get two different answers") but it seems like we've generally treated these issues as bugs and fixed the optimizations to be use-list-order independent in the past, no?) > (FWIW, there's some ancient discussion in PR5680 about this.) I don't have a strong opinion on whether depending on use-list order should be considered a bug. However, it *is* a bug not to be able to roundtrip to bitcode and get the same end result. While it may be possible to remove the compiler's dependency on use-list order, no one...

...to "run the compiler twice on the same input and get two different answers") but it seems like we've generally treated these issues as bugs and fixed the optimizations to be use-list-order independent in the past, no?) > > > > (FWIW, there's some ancient discussion in PR5680 about this.) > > I don't have a strong opinion on whether depending on use-list order > should be considered a bug. However, it *is* a bug not to be able to > roundtrip to bitcode and get the same end result. > > While it may be possible to remove the compiler's depende...

Forgot cc, the entire group. How can deterministically iterate over the uses of a variable. i.e. the uses should be any particular order that doesn't change from execution to execution of the opt tool. To make myself more clearer, here is a snippet of code that has Values reordered each time I analyze a particular piece of code(which doesn't change) with the LLVM opt tool and my LLVM

A while back I finished up some work [1] that Chad started to preserve use-list-order in bitcode [2], hidden behind an "experimental" option called `-preserve-bc-use-list-order`. I then added a similar `-preserve-ll-use-list-order` option for LLVM assembly [3]. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074604.html [2]: https://llvm.org/bugs/show_bug.cgi?id=5680 [3]: