Skip to content

release/19.x: [AVR] Fix 16-bit LDDs with immediate overflows (#104923) #106993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 24, 2024

Conversation

llvmbot
Copy link
Member

@llvmbot llvmbot commented Sep 2, 2024

Backport c7a4efa

Requested by: @EugeneZelenko

@Patryk27
Copy link
Contributor

@benshi001 / @aykevl, is there something we can do to push this forward or it's waiting for someone else?

@aykevl
Copy link
Contributor

aykevl commented Sep 12, 2024

I think it's up to the release managers now to merge this PR.

@tru
Copy link
Collaborator

tru commented Sep 13, 2024

Hi, since we are wrapping up LLVM 19.1.0 we are very strict with the fixes we pick at this point. Can you please respond to the following questions to help me understand if this has to be included in the final release or not.

Is this PR a fix for a regression or a critical issue?

What is the risk of accepting this into the release branch?

What is the risk of NOT accepting this into the release branch?

@Patryk27
Copy link
Contributor

Patryk27 commented Sep 13, 2024

Is this PR a fix for a regression or a critical issue?

It's a fix a critical issue within the AVR codegen which causes it to generate invalid binaries and/or crash llvm (depending on which concrete code path is taken).

It was spotted downstream in Rust, Rahix/avr-hal#573.

What is the risk of accepting this into the release branch?

The fix has been tested both within LLVM (as proven by the new tests added here) and by recompiling rustc and making sure the downstream project works correctly as well, so the risk is small.

What's more, the change is isolated to the AVR target - there's no way it could affect other targets.

What is the risk of NOT accepting this into the release branch?

Not huge, I think - rustc has its own fork of llvm-project where I could cherry-pick this commit anyway. Having backport is just the preferred way of the rustc team, but I think it's not a rule set in stone.

@tru
Copy link
Collaborator

tru commented Sep 16, 2024

This needs to be approved - can someone approve it and I'll merge it before final.

@Patryk27
Copy link
Contributor

cc @benshi001 / @aykevl 🙂

@benshi001 benshi001 self-requested a review September 17, 2024 00:36
Copy link
Member

@benshi001 benshi001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tru
Copy link
Collaborator

tru commented Sep 17, 2024

Unfortunately the tree was unstable right before release, so I had to direct my attention to reverting some patches instead of merging new ones. This will land in 19.1.1 instead.

16-bit loads are expanded into a pair of 8-bit loads, so the maximum
offset of such 16-bit loads must be 62, not 63.

(cherry picked from commit c7a4efa)
@tru tru merged commit b8b5050 into llvm:release/19.x Sep 24, 2024
7 of 10 checks passed
Copy link

@EugeneZelenko (or anyone else). If you would like to add a note about this fix in the release notes (completely optional). Please reply to this comment with a one or two sentence description of the fix. When you are done, please add the release:note label to this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

5 participants