Figure out what's needed to support rustc
#15
Labels
enhancement
New feature or request
help wanted
Extra attention is needed
wontfix
This will not be worked on
Comments
|
It's documented in the rustc dev guide: https://rustc-dev-guide.rust-lang.org/building/new-target.html |
|
TI-Planet's PB is just using the llvm branch of the toolchain, but yes there hasn't been much trouble lately, so it's in pretty good shape I'd say. We're not necessarily far from a releasable state, compiler+toolchain wise.
|
jacobly0
pushed a commit
that referenced
this issue
Dec 11, 2020
CXXDeductionGuideDecl with a local typedef has its own copy of the
TypedefDecl with the CXXDeductionGuideDecl as the DeclContext of that
TypedefDecl.
```
template <typename T> struct A {
typedef T U;
A(U, T);
};
A a{(int)0, (int)0};
```
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2020-November/067252.html
Without this fix, when we import the CXXDeductionGuideDecl (via
VisitFunctionDecl) then before creating the Decl we must import the
FunctionType. However, the first parameter's type is the afore mentioned
local typedef. So, we then start importing the TypedefDecl whose
DeclContext is the CXXDeductionGuideDecl itself. The infinite loop is
formed.
```
#0 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
#1 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:405:0
#2 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
#3 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
#4 clang::ASTImporter::ImportContext(clang::DeclContext*) clang/lib/AST/ASTImporter.cpp:8297:0
#5 clang::ASTNodeImporter::ImportDeclContext(clang::Decl*, clang::DeclContext*&, clang::DeclContext*&) clang/lib/AST/ASTImporter.cpp:1852:0
#6 clang::ASTNodeImporter::ImportDeclParts(clang::NamedDecl*, clang::DeclContext*&, clang::DeclContext*&, clang::DeclarationName&, clang::NamedDecl*&, clang::SourceLocation&) clang/lib/AST/ASTImporter.cpp:1628:0
#7 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) clang/lib/AST/ASTImporter.cpp:2419:0
#8 clang::ASTNodeImporter::VisitTypedefDecl(clang::TypedefDecl*) clang/lib/AST/ASTImporter.cpp:2500:0
#9 clang::declvisitor::Base<std::add_pointer, clang::ASTNodeImporter, llvm::Expected<clang::Decl*> >::Visit(clang::Decl*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/DeclNodes.inc:315:0
#10 clang::ASTImporter::ImportImpl(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8038:0
#11 clang::ASTImporter::Import(clang::Decl*) clang/lib/AST/ASTImporter.cpp:8200:0
#12 llvm::Expected<clang::TypedefNameDecl*> clang::ASTNodeImporter::import<clang::TypedefNameDecl>(clang::TypedefNameDecl*) clang/lib/AST/ASTImporter.cpp:165:0
#13 clang::ASTNodeImporter::VisitTypedefType(clang::TypedefType const*) clang/lib/AST/ASTImporter.cpp:1304:0
#14 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:74:0
#15 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
#16 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
#17 clang::ASTNodeImporter::VisitFunctionProtoType(clang::FunctionProtoType const*) clang/lib/AST/ASTImporter.cpp:1244:0
#18 clang::TypeVisitor<clang::ASTNodeImporter, llvm::Expected<clang::QualType> >::Visit(clang::Type const*) /home/egbomrt/WORK/llvm5/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:47:0
#19 clang::ASTImporter::Import(clang::QualType) clang/lib/AST/ASTImporter.cpp:8071:0
#20 llvm::Expected<clang::QualType> clang::ASTNodeImporter::import<clang::QualType>(clang::QualType const&) clang/lib/AST/ASTImporter.cpp:179:0
#21 clang::QualType clang::ASTNodeImporter::importChecked<clang::QualType>(llvm::Error&, clang::QualType const&) clang/lib/AST/ASTImporter.cpp:198:0
#22 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) clang/lib/AST/ASTImporter.cpp:3313:0
#23 clang::ASTNodeImporter::VisitCXXDeductionGuideDecl(clang::CXXDeductionGuideDecl*) clang/lib/AST/ASTImporter.cpp:3543:0
```
The fix is to first create the TypedefDecl and only then start to import
the DeclContext.
Basically, we could do this during the import of all other Decls (not
just for typedefs). But it seems, there is only one another AST
construct that has a similar cycle: a struct defined as a function
parameter:
```
int struct_in_proto(struct data_t{int a;int b;} *d);
```
In that case, however, we had decided to return simply with an error
back then because that seemed to be a very rare construct.
Differential Revision: https://reviews.llvm.org/D92209
jacobly0
pushed a commit
that referenced
this issue
Feb 28, 2021
The Select insn in BPF is expensive as BPF backend needs to resolve with conditionals. This patch set the getCmpSelInstrCost() to SCEVCheapExpansionBudget for Select insn to prevent some Select insn related optimizations. This change is motivated during bcc code review for iovisor/bcc#3270 where IndVarSimplifyPass eventually caused generating the following asm code: ; for (i = 0; (i < VIRTIO_MAX_SGS) && (i < num); i++) { 14: 16 05 40 00 00 00 00 00 if w5 == 0 goto +64 <LBB0_6> 15: bc 51 00 00 00 00 00 00 w1 = w5 16: 04 01 00 00 ff ff ff ff w1 += -1 17: 67 05 00 00 20 00 00 00 r5 <<= 32 18: 77 05 00 00 20 00 00 00 r5 >>= 32 19: a6 01 01 00 05 00 00 00 if w1 < 5 goto +1 <LBB0_4> 20: b7 05 00 00 06 00 00 00 r5 = 6 00000000000000a8 <LBB0_4>: 21: b7 02 00 00 00 00 00 00 r2 = 0 22: b7 01 00 00 00 00 00 00 r1 = 0 ; for (i = 0; (i < VIRTIO_MAX_SGS) && (i < num); i++) { 23: 7b 1a e0 ff 00 00 00 00 *(u64 *)(r10 - 32) = r1 24: 7b 5a c0 ff 00 00 00 00 *(u64 *)(r10 - 64) = r5 Note that insn #15 has w1 = w5 and w1 is refined later but r5(w5) is eventually saved on stack at insn #24 for later use. This cause later verifier failures. With this change, IndVarSimplifyPass won't do the above transformation any more. Differential Revision: https://reviews.llvm.org/D97479
|
You may try to compile rust code as described here: http://forum.6502.org/viewtopic.php?p=84048#p84048 6502 backend is very incomplete yet, but I was able to produce working executable this way. The trick is to compile rust code to llvm-ir first ( |
|
I was able to build a crate using Cargo and then use this method to have Clang compile and link all of the IR files. Unfortunately this means I still don't have access to the core library. There's also the issue that all I can figure out how to get is assembly in GAS syntax which I don't know of any Z80 assembler for. Still, it's fascinating to read through the generated code. |
|
I tried that. I followed along with the changes made by @mrk-its to make a Rust compiler for the 6502 in his form, but for the Z80 instead. But unfortunately, I just ended up getting LLVM to segfault when I tried that. So I just wrote a custom JSON target specification (telling it that it was ARM, but changing all the data sizes to match the Z80), got it to generate IR, and then fed that into Clang. |
|
I tried compiling However, llc outputs this: |
|
The person I forked this from to try out called it "a proof of concept" but then I start using the core library (I updated the compiler to the latest commit, see my fork) and it does not work properly. LLVM seems to not understand this |
|
The asm generated by the compiler, when targeting (e)z80, is made for the fasmg assembler with specific support for that target, see for example how it's used in here: https://github.com/CE-Programming/toolchain
|
|
Which compiler are you talking about exactly? rustc or llc Edit: maybe related to this? rust-lang/rust#58567 |
|
That error means that the calling convention code didn't support however the function was trying to return. |
|
Hello, maybe it can help as an example: rust-lang/rust#88321 |
|
Closing because I don't have plans to work on this, feel free to continue discussing or reopen if someone wants to have this issue assigned to them. |
jacobly0
added
enhancement
|
I've been trying my hand at this and so far I've started with rust 1.65 as a base, since it has the most similar LLVM version to this project, and then merged this z80 branch into that one and rebuilt rust from src. All the steps work up until trying to transpile the LLVM bytecode into ASM (I think that's what it's doing? I'm still new to working with low-level LLVM forgive me if I'm misnaming or misunderstanding something). Wondering if I could get someone help that knows more about LLVM. It seems it's failing at translating a call instruction that has a non-primitive type. Here is an example of the LLVM bytecode I'm trying to compile: ; ModuleID = 'calculator_snake-bf64b38161ffb5f6.3wbn5zfgu27wxvpa.rcgu.o'
source_filename = "3wbn5zfgu27wxvpa"
target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20"
target triple = "ez80"
%"calculator_snake::ffi::types::ti_uint" = type { [3 x i8] }
@alloc1 = private unnamed_addr constant <{ [21 x i8] }> <{ [21 x i8] c"Running Screen Test \00" }>, align 1
@alloc2 = private unnamed_addr constant <{ [38 x i8] }> <{ [38 x i8] c"Press Enter to progress to next test \00" }>, align 1
; Function Attrs: nounwind
define dso_local void @main() unnamed_addr #0 {
start:
%0 = tail call %"calculator_snake::ffi::types::ti_uint" @os_PutStrFull(ptr nonnull @alloc1) #1
tail call void @os_NewLine() #1
%1 = tail call %"calculator_snake::ffi::types::ti_uint" @os_PutStrFull(ptr nonnull @alloc2) #1
br label %bb6
bb6: ; preds = %bb6, %start
%2 = tail call noundef zeroext i16 @os_GetKey() #1, !range !1
%.not = icmp eq i16 %2, 5
br i1 %.not, label %bb10, label %bb6
bb10: ; preds = %bb6
tail call void @os_ClrLCD() #1
ret void
}
; Function Attrs: nounwind
declare dso_local %"calculator_snake::ffi::types::ti_uint" @os_PutStrFull(ptr) unnamed_addr #0
; Function Attrs: nounwind
declare dso_local void @os_NewLine() unnamed_addr #0
; Function Attrs: nounwind
declare dso_local noundef zeroext i16 @os_GetKey() unnamed_addr #0
; Function Attrs: nounwind
declare dso_local void @os_ClrLCD() unnamed_addr #0
attributes #0 = { nounwind "target-cpu"="generic" }
attributes #1 = { nounwind }
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"LTOPostLink", i32 1}
!1 = !{i16 1, i16 252}Changing the %0 = tail call %"calculator_snake::ffi::types::ti_uint" @os_PutStrFull(ptr nonnull @alloc1) #1
tail call void @os_NewLine() #1
%1 = tail call %"calculator_snake::ffi::types::ti_uint" @os_PutStrFull(ptr nonnull @alloc2) #1to %0 = tail call i32 @os_PutStrFull(ptr nonnull @alloc1) #1
tail call void @os_NewLine() #1
%1 = tail call i32 @os_PutStrFull(ptr nonnull @alloc2) #1Compiles successfully (of course being actually incorrect) Here is the full stack trace of the failed compile: Any help would be greatly appreciated! |
Have you made any progress on this? I pulled out my RC2014 today and went to see if there had been any progress on Rust support for the z80 |
jacobly0
pushed a commit
that referenced
this issue
Aug 17, 2024
A case for this transformation, https://gcc.godbolt.org/z/nhYcWq1WE Fold mov w8, llvm#56952 movk w8, #15, lsl #16 ldrb w0, [x0, x8] into add x0, x0, 1036288 ldrb w0, [x0, 3704] Only LDRBBroX is supported for the first time. Fix llvm#71917 Note: This PR is try relanding the commit 32878c2 with fix crash for PR79756 this crash is exposes when there is MOVKWi instruction in the head of a block, but without MOVZWi
jacobly0
pushed a commit
that referenced
this issue
Oct 9, 2024
…ext is not fully initialized (llvm#110481) As this comment around target initialization implies: ``` // This can be NULL if we don't know anything about the architecture or if // the target for an architecture isn't enabled in the llvm/clang that we // built ``` There are cases where we might fail to call `InitBuiltinTypes` when creating the backing `ASTContext` for a `TypeSystemClang`. If that happens, the builtins `QualType`s, e.g., `VoidPtrTy`/`IntTy`/etc., are not initialized and dereferencing them as we do in `GetBuiltinTypeForEncodingAndBitSize` (and other places) will lead to nullptr-dereferences. Example backtrace: ``` (lldb) run Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file Type.h, line 958. Process 2680 stopped * thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) + liblldb.20.0.0git.dylib`DWARFASTParserClang::ParseObjCMethod(lldb_private::ObjCLanguage::MethodName const&, lldb_private::plugin::dwarf::DWARFDIE const&, lldb_private::CompilerType, ParsedDWARFTypeAttributes , bool) (.cold.1): -> 0x10cdf3cdc <+0>: stp x29, x30, [sp, #-0x10]! 0x10cdf3ce0 <+4>: mov x29, sp 0x10cdf3ce4 <+8>: adrp x0, 545 0x10cdf3ce8 <+12>: add x0, x0, #0xa25 ; "ParseObjCMethod" Target 0: (lldb) stopped. (lldb) bt * thread #15, name = '<lldb.process.internal-state(pid=2712)>', stop reason = hit program assert frame #0: 0x0000000180d08600 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x0000000180d40f50 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x0000000180c4d908 libsystem_c.dylib`abort + 128 frame #3: 0x0000000180c4cc1c libsystem_c.dylib`__assert_rtn + 284 * frame #4: 0x000000010cdf3cdc liblldb.20.0.0git.dylib`DWARFASTParserClang::ExtractIntFromFormValue(lldb_private::CompilerType const&, lldb_private::plugin::dwarf::DWARFFormValue const&) const (.cold.1) + frame #5: 0x0000000109d30acc liblldb.20.0.0git.dylib`lldb_private::TypeSystemClang::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding, unsigned long) + 1188 frame #6: 0x0000000109aaaed4 liblldb.20.0.0git.dylib`DynamicLoaderMacOS::NotifyBreakpointHit(void*, lldb_private::StoppointCallbackContext*, unsigned long long, unsigned long long) + 384 ``` This patch adds a one-time user-visible warning for when we fail to initialize the AST to indicate that initialization went wrong for the given target. Additionally, we add checks for whether one of the `ASTContext` `QualType`s is invalid before dereferencing any builtin types. The warning would look as follows: ``` (lldb) target create "a.out" Current executable set to 'a.out' (arm64). (lldb) b main warning: Failed to initialize builtin ASTContext types for target 'some-unknown-triple'. Printing variables may behave unexpectedly. Breakpoint 1: where = a.out`main + 8 at stepping.cpp:5:14, address = 0x0000000100003f90 ``` rdar://134869779
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rust seems like an attractive language to support on TI Calculators (and other (e)Z80 platforms):
Therefore, I'm opening this issue to try and get the discussion moving forward!
The text was updated successfully, but these errors were encountered: