[AVR] Fix IRGen function emission to respect LLVM DataLayout program address space. #78810
Conversation
|
Could I ask for just a commit message adjustment? It currently implies this is a test-only change, but in reality it's not. |
|
Sure thing. I'll fix that. Cheers! |
carlos4242
force-pushed
the
avr-irgen-functions-respect-llvm-datalayout
branch
from
eec7e74 to
7df40ff
Compare
carlos4242
changed the title
|
Apologies for that @kubamracek ... a mistake with my commit messages when doing an interactive rebase to squash commits. Now it's a bit easier to see what it's doing properly. |
|
@swift-ci please test |
…ding with the correct fixups for program memory on AVR.
|
While waiting for review I came up with another unit test and pushed it, IR emission is working properly right down to object files/assembly, but it requires -O... that's OK because you really can't use non-optimised microcontroller code, it won't fit on the chip! |
|
@kubamracek @eeckstein hi guys, I'm not sure what state this is in? Is it fit to merge? If you'd rather pick it up after WWDC I understand. I left it for a few months so people could give their feedback but I'm feeling like I might need to do something to move it on? Carl |
|
@kubamracek any objections merging this PR? |
[AVR] Fix IRGen function emission to respect LLVM DataLayout program address space.
[IRGen/LLVM] Fix broken IRGen emission not respecting LLVM Datalayout
IRGen crashes when attempting to lower even the most basic Swift programs on AVR. I have encountered many problems similar to this over the years and it's always to do with program address space. (See forum discussion: https://forums.swift.org/t/avr-irgen-traps-on-lowering-invalid-cast-assertion-thrown-by-llvm/76883).
This seems to work for at least basic IRGen functionality on AVR. We may need more PRs in future for AVR but this is a start at least.
This is the approach I took on my fork, changing the structure of IRGenModule a bit to separate out
FunctionPtrTy, if this is too intrusive for other platforms, I'm happy to use another approach, whatever seems sensible. I'm not attached to any one approach.Note: AVR uses pointers with a different address space for program (flash) memory on the microcontrollers to distinguish RAM from Flash memory. Because AVR uses 16-bit pointers, there are not enough addresses to keep the two types of memory separate otherwise. This is well established in LLVM now (it has been in mainstream LLVM for years now) and all other AVR front ends (Rust, C, TinyGo) depend on it.
Resolves #78380
@kubamracek @rauhul @phausler