Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < apilipenko at azulsystems.com> wrote:> Are you going to run some of the existing passes? Why can’t you just use > the returned change-made value from the passes? > > Artur > > > On 20 Dec 2015, at 15:43, Russell Wallace via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I want to run a bunch of optimizations, iteratively, that is keep > running until things stop changing (to make sure all optimization > opportunities are taken). As far as I know, there is no way to copy a > module or compare modules by value, so it occurs to me that a practical > solution might be to take the hash code of the module and see if that > changes. > > > > A problem is that hash algorithms are designed to work on streams of > bytes, not compound objects. > > > > First attempt at a solution: iterate through all instructions in all > functions and hash the instruction kinds. I can think of some possible > changes that would fail to be captured by that. > > > > Is there any already known solution? > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/7e5e3ff0/attachment.html>
There is a caveat here. I was experimenting with something similar and found that this status is not always trustworthy. I fixed one bug in prune-eh. These is also a bug in reassociate pass. It returns true with no change made on the following instruction: %0 = and i64 %b, %a It happens because it performs two distinct transformations which nullify each other (canonicalizeOperands swaps arguments of an and and then ReassociateExpression swaps them back). This approach might work for your set of passes, but beware of the problem. Artur On 21 Dec 2015, at 19:59, Russell Wallace <russell.wallace at gmail.com<mailto:russell.wallace at gmail.com>> wrote: Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> wrote: Are you going to run some of the existing passes? Why can’t you just use the returned change-made value from the passes? Artur> On 20 Dec 2015, at 15:43, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > > I want to run a bunch of optimizations, iteratively, that is keep running until things stop changing (to make sure all optimization opportunities are taken). As far as I know, there is no way to copy a module or compare modules by value, so it occurs to me that a practical solution might be to take the hash code of the module and see if that changes. > > A problem is that hash algorithms are designed to work on streams of bytes, not compound objects. > > First attempt at a solution: iterate through all instructions in all functions and hash the instruction kinds. I can think of some possible changes that would fail to be captured by that. > > Is there any already known solution? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/81eec098/attachment.html>
Oh, hmm, thanks for the warning, I should probably stick with the copy and compare technique then. On Mon, Dec 21, 2015 at 5:11 PM, Artur Pilipenko <apilipenko at azulsystems.com> wrote:> There is a caveat here. I was experimenting with something similar and > found that this status is not always trustworthy. I fixed one bug in > prune-eh. These is also a bug in reassociate pass. It returns true with no > change made on the following instruction: > %0 = and i64 %b, %a > It happens because it performs two distinct transformations which nullify > each other (canonicalizeOperands swaps arguments of an and and then > ReassociateExpression swaps them back). > > This approach might work for your set of passes, but beware of the problem. > > Artur > > On 21 Dec 2015, at 19:59, Russell Wallace <russell.wallace at gmail.com> > wrote: > > Yes, I'm running all the existing passes that I know how to run. I didn't > know they returned change-made. Thanks! > > On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < > apilipenko at azulsystems.com> wrote: > >> Are you going to run some of the existing passes? Why can’t you just use >> the returned change-made value from the passes? >> >> Artur >> >> > On 20 Dec 2015, at 15:43, Russell Wallace via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > >> > I want to run a bunch of optimizations, iteratively, that is keep >> running until things stop changing (to make sure all optimization >> opportunities are taken). As far as I know, there is no way to copy a >> module or compare modules by value, so it occurs to me that a practical >> solution might be to take the hash code of the module and see if that >> changes. >> > >> > A problem is that hash algorithms are designed to work on streams of >> bytes, not compound objects. >> > >> > First attempt at a solution: iterate through all instructions in all >> functions and hash the instruction kinds. I can think of some possible >> changes that would fail to be captured by that. >> > >> > Is there any already known solution? >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/40b07395/attachment.html>
| (canonicalizeOperands swaps arguments of an and and then ReassociateExpression swaps them back). That feels like its own bug, canonicalize and reassociate having different opinions of canonical order. Just saying. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Artur Pilipenko via llvm-dev Sent: Monday, December 21, 2015 9:11 AM To: Russell Wallace Cc: llvm-dev Subject: Re: [llvm-dev] Hash of a module There is a caveat here. I was experimenting with something similar and found that this status is not always trustworthy. I fixed one bug in prune-eh. These is also a bug in reassociate pass. It returns true with no change made on the following instruction: %0 = and i64 %b, %a It happens because it performs two distinct transformations which nullify each other (canonicalizeOperands swaps arguments of an and and then ReassociateExpression swaps them back). This approach might work for your set of passes, but beware of the problem. Artur On 21 Dec 2015, at 19:59, Russell Wallace <russell.wallace at gmail.com<mailto:russell.wallace at gmail.com>> wrote: Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> wrote: Are you going to run some of the existing passes? Why can’t you just use the returned change-made value from the passes? Artur> On 20 Dec 2015, at 15:43, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > > I want to run a bunch of optimizations, iteratively, that is keep running until things stop changing (to make sure all optimization opportunities are taken). As far as I know, there is no way to copy a module or compare modules by value, so it occurs to me that a practical solution might be to take the hash code of the module and see if that changes. > > A problem is that hash algorithms are designed to work on streams of bytes, not compound objects. > > First attempt at a solution: iterate through all instructions in all functions and hash the instruction kinds. I can think of some possible changes that would fail to be captured by that. > > Is there any already known solution? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/89b68602/attachment.html>