<div dir="ltr">> I agree. If a pass modifies the IR in any way, even temporarily, it was changed (at some point).<br><div> I'd like to +1, but when doing the migration of the code base to enable the associated expensive check, I found situations where (B) was used.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 18, 2020 at 5:20 AM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 7/17/20 2:57 PM, Roman Lebedev via llvm-dev wrote:<br>
> On Fri, Jul 17, 2020 at 10:52 PM Nikita Popov via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> On Fri, Jul 17, 2020 at 9:30 PM Jonathan Roelofs via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t).<br>
>>><br>
>>> This raises a broader question of what we really mean when we say that a pass is allowed to report it made no changes through its runOn* function(s):<br>
>>><br>
>>> A) The obvious, and most restrictive condition would be that the pass can only return false if it treated the Function/Module/etc that it visited purely as read-only. From what I can tell, a lot of passes conservatively assume this is the required condition.<br>
>>><br>
>>> B) Less obvious would be that we allow passes to add instructions speculatively, so long as they remove whatever they added before returning false. If one were to dump the IR before & after such a pass, you should see no change in the text/bitcode. If you compared the in-memory representations, you should see no semantic differences in the two, modulo “allowed” differences like unordered lists of pointers (I vaguely remember a few cases of this existing, but can’t remember the details).<br>
>>><br>
>>> C) Even less obvious would be that we allow a pass that removes instructions / globals, and then re-adds them. These changes would be semantics-preserving, but would of course not preserve the removed bits of IR’s addresses in memory.<br>
>>><br>
>>> I believe (A) to be the spirit of the contract between passes and the pass manager. (B) seems like a stretch, but depending on the analysis invalidation needs of the PM, might still be ok. (C) seems totally off base, and does not seem like a productive interpretation.<br>
>>><br>
>>> Does this match everyone else’s intuition, and is (B) even a valid interpretation?<br>
>><br>
>> This concern was brought up in the relevant review (<a href="https://reviews.llvm.org/D81230" rel="noreferrer" target="_blank">https://reviews.llvm.org/D81230</a>) as well.<br>
>> I think we can safely go with (A) here. It's unambiguous, and I don't think there's any practical benefit to be had from (B) or (C).<br>
> +1<br>
<br>
I agree. If a pass modifies the IR in any way, even temporarily, it was <br>
changed (at some point).<br>
<br>
<br>
><br>
>> Regards,<br>
>> Nikita<br>
> Roman<br>
><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>