Build A Sample Source Language For LLVM #508
Comments
|
P.S. We might want to create a new Bugzilla "Product" for "Projects" so this bug |
|
Stacker Compiler And Runtime V1.0 Documentation will follow tomorrow (it's 1/2 written). |
|
THE THING TO NOTE FROM THIS EXERCISE: Note the time stamps on the previous to postings. The first is when I started. That ALONE is a testimony to LLVM. I've never gotta a native machine capable |
|
Great!! I checked it in. Here are a couple of things that could be improved:
... which I fixed with this patch:
gcc -ggdb -L/home/vadve/lattner/cvs/llvm/lib/Debug testing.s -lstkr_runtime -o ... This is probably a bug in the X86 code generator, not outputting stuff with
Overall, this looks really cool, and should be useful to a lot of people! I'm -Chris |
|
I'm working these problems .. there's bigger issues .. configure.ac isn't right Reid. |
|
Hey! The Stacker compilation errors you described only occurred after I did a cvs Reid. |
|
Patch To Fix Integration Issues
NOTE: You will need a patched configure.ac and configure script to make this |
|
Patch To Fix Configuration Of Stacker Directories |
|
Documentation For Stacker This file is meant to be dropped into the docs subdirectory. It references |
|
I'm going to leave this unresolved until I get confirmation that at least one The remaining documentation tasks will get completed as time permits. Reid. |
This was because I added the assertion to the verifier to ensure that you Brian, can you check in the patches after the "1.0" patch when you get a chance? Thanks all, -Chris |
|
The patches are in. I disabled Stacker/{test,samples} because they currently |
|
Documentation Update For Stacker This document is pretty much done except for the "internals" section at the end |
|
Applied, thanks. |
|
Another Documentation Update This patch cleans up several typos and adds a "to do" list. |
|
I attempted to apply your "Another Documentation Update" patch, but it didn't -Chris |
|
That's strange. I just tested the patch again (like I always do) against the Did you:
Do you want to me post the patch again in case it got corrupted in transit? Reid. |
|
This is what I get, from CVS. The previous patch was applied by Brian (this I ~/llvm$ patch -p0 < doc.patch Also, this:
is buggy: it should not have the 'new' there. :) -Chris |
|
Another Documentation Patch (Round 2)! bash-2.05b$ mv Stacker.html Stacker.html.save The same >should< work for you. |
|
That worked, but not from the top level. :) Applied. -Chris |
|
Oops, forgot to copy my "cd" command in the last post. I wanted to ensure there Reid |
|
Stacker has been applied to mainline, so I think this PR is done for now. Any -Chris |
|
Patch to fix Makefile in tests directory - remove dependency on users environment. |
|
[A patch to fix Makefile in projectshttps://user-images.githubusercontent.com/60944935/143736175-fec127e4-86a8-47c9-a5d6-5c2ac9c9a419.gz) |
|
These two patches are a definite improvement, and have been applied, but they In particular, it would be good to make better use of the things defined in LLC_EXEC = $(LLVMTOOLCURRENT)/llc Better yet, all of the variables that define the locations of tools could be Also, instead of hardcoding in the use of gcc, it would probably be better to Overall, I'd like to see stacker become more of a first class citizen in the -Chris |
|
Minor edits and corrections to the documentation |
|
Committed, thanks! -Chris |
We start our journey towards `goto` support and this is a first step on this way. There are some discussion in llvm#508 and according to the plan we do the following here: - a new pass called `cir-flatten-cfg` that is a stub now but later will be responsible for the regions inlining. The pass works only if `-emit-flat-cir` is passed in cmd line. Thus, the clang behavior is not changed here from the user's point of view. - The pass will be accomplished with `goto` solver later, so we talk about several passes that are mandatory for the lowering into `llvm` dialect. There are at least two clients of this pass that will be affected: `clang` itself and `cir-opt`, so we need a common point for them: and `populateCIRFlatteningPasses` and `populateCIRToLLVMPasses` guarantee that `CIR` will be in the correct state for all the clients, whatever new passes we will add later.
We start our journey towards `goto` support and this is a first step on this way. There are some discussion in llvm#508 and according to the plan we do the following here: - a new pass called `cir-flatten-cfg` that is a stub now but later will be responsible for the regions inlining. The pass works only if `-emit-flat-cir` is passed in cmd line. Thus, the clang behavior is not changed here from the user's point of view. - The pass will be accomplished with `goto` solver later, so we talk about several passes that are mandatory for the lowering into `llvm` dialect. There are at least two clients of this pass that will be affected: `clang` itself and `cir-opt`, so we need a common point for them: and `populateCIRFlatteningPasses` and `populateCIRToLLVMPasses` guarantee that `CIR` will be in the correct state for all the clients, whatever new passes we will add later.
We start our journey towards `goto` support and this is a first step on this way. There are some discussion in llvm#508 and according to the plan we do the following here: - a new pass called `cir-flatten-cfg` that is a stub now but later will be responsible for the regions inlining. The pass works only if `-emit-flat-cir` is passed in cmd line. Thus, the clang behavior is not changed here from the user's point of view. - The pass will be accomplished with `goto` solver later, so we talk about several passes that are mandatory for the lowering into `llvm` dialect. There are at least two clients of this pass that will be affected: `clang` itself and `cir-opt`, so we need a common point for them: and `populateCIRFlatteningPasses` and `populateCIRToLLVMPasses` guarantee that `CIR` will be in the correct state for all the clients, whatever new passes we will add later.
…tream_merge_20250205082821 merge main into amd-staging
We start our journey towards `goto` support and this is a first step on this way. There are some discussion in llvm#508 and according to the plan we do the following here: - a new pass called `cir-flatten-cfg` that is a stub now but later will be responsible for the regions inlining. The pass works only if `-emit-flat-cir` is passed in cmd line. Thus, the clang behavior is not changed here from the user's point of view. - The pass will be accomplished with `goto` solver later, so we talk about several passes that are mandatory for the lowering into `llvm` dialect. There are at least two clients of this pass that will be affected: `clang` itself and `cir-opt`, so we need a common point for them: and `populateCIRFlatteningPasses` and `populateCIRToLLVMPasses` guarantee that `CIR` will be in the correct state for all the clients, whatever new passes we will add later.
Extended Description
As an enhancement to LLVM and a vehicle for both learning LLVM and (possibly)
testing LLVM through an alternate source language, I'm building a front end for
a very simple language named Stacker. It is somewhat Forth based but doesn't
nearly have the expressive power of ANS Forth. The syntax will be familiar to
Forth programmers but the capabilities very limiting.
The initial version will have the following restrictions:
As such, the language is barely higher level than LLVM Assembly.
The point is to produce a simple language with a simple grammar and lexical
analyzer that demonstrates how to use LLVM classes to generate bytecode and
execute them with JIT, etc.
This "bug" (enhancement) is provided just to track the work, design, patches,
extensions, etc.
The text was updated successfully, but these errors were encountered: