Displaying 6 results from an estimated 6 matches for "d81230".
Did you mean:
d21230
2020 Jun 11
4
[RFC] Pass return status
...[1] is appreciated.
Once that check lands and we're relatively confident on the quality of the
return status, some more optimizations could be triggered, like
https://reviews.llvm.org/D80707.
[0] https://llvm.org/docs/WritingAnLLVMPass.html#the-runonmodule-method
[1] https://reviews.llvm.org/D81230
https://reviews.llvm.org/D81236
https://reviews.llvm.org/D81256
https://reviews.llvm.org/D81238
https://reviews.llvm.org/D81225
2020 Jul 15
3
[RFC] Pass return status
...defend against human mistakes and save countless hours of debugging
> when subtle issues arise.
>
> Thanks Serge,
>
> --
> Mehdi
>
>
>
>>
>>
>> [0] https://llvm.org/docs/WritingAnLLVMPass.html#the-runonmodule-method
>> [1] https://reviews.llvm.org/D81230
>> https://reviews.llvm.org/D81236
>> https://reviews.llvm.org/D81256
>> https://reviews.llvm.org/D81238
>> https://reviews.llvm.org/D81225
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-d...
2020 Jul 17
4
Allowed operations for passes that report "no change"
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).
This raises a
2020 Jul 17
2
Allowed operations for passes that report "no change"
...the PM, might still be ok. (C) seems totally off base, and does not seem like a productive interpretation.
>>
>> Does this match everyone else’s intuition, and is (B) even a valid interpretation?
>
>
> This concern was brought up in the relevant review (https://reviews.llvm.org/D81230) as well.
> 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).
+1
> Regards,
> Nikita
Roman
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev...
2020 Jul 16
2
[RFC] Pass return status
...urs of debugging
>> when subtle issues arise.
>>
>> Thanks Serge,
>>
>> --
>> Mehdi
>>
>>
>>
>>>
>>>
>>> [0] https://llvm.org/docs/WritingAnLLVMPass.html#the-runonmodule-method
>>> [1] https://reviews.llvm.org/D81230
>>> https://reviews.llvm.org/D81236
>>> https://reviews.llvm.org/D81256
>>> https://reviews.llvm.org/D81238
>>> https://reviews.llvm.org/D81225
>>>
>>> _______________________________________________
>>> LLVM Developers...
2020 Jul 20
2
Allowed operations for passes that report "no change"
...f
> base, and does not seem like a productive interpretation.
> >>>
> >>> Does this match everyone else’s intuition, and is (B) even a valid
> interpretation?
> >>
> >> This concern was brought up in the relevant review (
> https://reviews.llvm.org/D81230) as well.
> >> 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).
> > +1
>
> I agree. If a pass modifies the IR in any way, even temporarily, it was
> changed (at some point)....