Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion: this kinda feels backwards to me, I feel like if autodiff is applied to some fn it should inhibit inlining. Is there a small test case (synthetic or not) that can demonstrate this change? Or rather, under what situation can this condition be previously wrong (the change itself looks reasonable)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I add inline(never) in my frontend macro to source and target function. However, those aren't guaranteedon a language level to prevent inlinung, so I additionally check it here in rustc_monomorphize. So yes, autodiff prevents inlining. (Edited a bit, but I think I still miss your point).
https://doc.rust-lang.org/nightly/reference/attributes/codegen.html?highlight=inline
Pretty much every codegen test will fail if you remove these two barriers.
The change btw. is needed since we currently also inspect non fn items like Asm, which triggers a debug assertion, causing bootstrap to fail. But you already mentioned that this looks reasonable to you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moreso meant if there's a smaller example that would fail without this PR, not changing the front-end/middle-end bits, as a regression test.
... But also not building -> building seems like an improvement, yes 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aah, yes now I get your question. I only mentioned it in the title, not the PR body, but you can find the panic stacktrace in the linked issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#140064 (comment)
@jieyouxu since you already looked at it, it's a one line change, fixes bootstrap and eliminates the ad overhead, do you mind to rubberstamp it? Then I can drop it from my final enable-aitodiff PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, at least this makes it possible to build, and I can't come up with a smaller test...