[llvm-dev] Hash of a module

[Russell Wallace via llvm-dev]

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>