Skip to content

Fix for avr-rust issue 129 #9

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

Closed
wants to merge 3 commits into from
Closed

Fix for avr-rust issue 129 #9

wants to merge 3 commits into from

Conversation

carlos4242
Copy link

The bug is related to parameter ordering and endianness. (See avr-rust rust-lang#129.)

When a large type can't be legalised, it's broken into smaller types, those are passed as parameters in order based on the endianness of the platform, which is wrong in the case of AVR (at least) because of the way those parameters are then reversed into a semi-big-endian order for the AVR GCC ABI.

The problem is the legalising is in shared code, without any existing platform specific hooks that seemed appropriate, so I added an overridable function into the TypeLoweringInfo, overridden appropriately on the AVR platform to correct the issue on AVR.

Open to comments/suggestions, also...

i) this is not yet a complete fix because the return values are suffering a similar issue too
ii) the unit test is not complete, it doesn't yet test anything

…nvention endianness as it does not always match the overall endianness.

When an argument is too large to be legalised by the architecture and is split for the ABI, we may need flexibility how we order the resulting parameters.
(alternative approach recommended by Eli Friedman)
@carlos4242 carlos4242 changed the title WIP: fix for avr-rust issue 129 Fix for avr-rust issue 129 Mar 10, 2019
@carlos4242
Copy link
Author

Just pushed a unit test that detects the issue. Also the problem with return values is part of a more general regression, caused by some work in rust-lang#92, also tracked in rust-lang#130 and fixed by PR #10.

Copy link
Member

@dylanmckay dylanmckay left a comment

Choose a reason for hiding this comment

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

Nice work @carlos4242

- more test cleanup
- name change
@shepmaster
Copy link
Member

@dylanmckay no pressure intended, but the "easiest" way to get these PRs from this repo into the new llvm-project repo would be to merge them into upstream LLVM and then we can cherry-pick them 😉

@dylanmckay
Copy link
Member

I'll stop being an intermittent maintainer someday ;)

This is looking really nice, I'm gonna do something with it tonight, I promise!!

@dylanmckay
Copy link
Member

Raised https://reviews.llvm.org/D62003 for upstreaming.

@carlos4242
Copy link
Author

Cool. Let me know if I should do anything else at all?

@carlos4242 carlos4242 closed this May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants