[llvm-dev] LLVM Backend for a platform with no (normal) stack

[JD Jones via llvm-dev]

Yes, thank you, specifically and all.  On this platform, we call what I will use a "frame stack" (it's actually not a stack, but that's really not relevant).  Special thanks to Mr. Mendell--I promise to make good use of the contents of lib/Transforms/Utils/PromoteMemoryToRegister.cpp.

To All, I'm sorry I wasn't clear in my original posting. In hindsight, it was clearly not clear. More apologies.

I am looking for information on projects that actually implemented an LLVM backend on a platform that has no normal call stack, the project's reasoning, timelines, lessons-learned, that sort of thing, or research/analysis that explains why LLVM was not used for such a backend.

Perhaps the reasons for the posting would help? If not, please read no further, just please accept more, sincere thanks and requests for forgiveness.

<<DANGER, WILL ROBINSON! LONG EMAIL AHEAD!  DANGER!>>

My hope was to obtain information about/from  projects that _have actually performed_ (or decided _not_ to perform) a task similar to mine. Because...
 
My superordinates have read that it's quick and easy to create an LLVM backend.

On 11/27, I was tasked to create a "super basic" LLVM backend for a platform that has no stack--something the core LLVM code seems to assume.

My superordinates expect to see that backend by the end of this month. 

"Super basic" means a translation from C, "int main() { int a = 1; int b = 2; int c = a+b; return c; }", into the assembly code used by our (likely unique) platform. What I've got generates "hmninh" where I need to work inside the prologue and epilogue, and a few of my platform's assembly instructions in almost the right places. This week, I'll be looking for those places in the DAG processing where I need to add (or prevent the consolidation of) nodes, subtract (or prevent the addition of) nodes, etc.. I'm getting the hang of LLVM enough to cause a little damage.

ADHD moment: praises to those folks who thought to add -debug to llc and those who thoughtfully populate and filter it.

When I sent my first email request for help, I was thinking along the lines of the generously provided, previous suggestions (Mr. Hoult, Mr. Korobeynikov, thank you again!), to just "make a stack" using what I've got, but that's not the way the current compiler (which was written in Haskell) does things. I was hoping for some thoughts about which way to go, and the responses validated and gladdened.

I know _now_ that implementing an equivalent of a normal call stack on this platform is disallowed. I know this because after my first email, a superordinate told me "No stack", spouted Greek at me for a few long minutes, then asked "Got it?"  I replied, "No stack. Got it."

So, I basically need to port/re-invent some of the Haskell code (from the current compiler) inside of and using the LLVM infrastructure (otherwise, it won't be an "LLVM backend").

I can do this.

I do _not_ know _how much_ of it I can do by New Year's Eve. My superordinates have shown a disinclination to accept my word as a professional, experienced engineer that I'm doing the right things in a reasonable manner at the optimal speed. They believe their own research over mine unless I thoroughly defend it.

With no other project as a basis of estimate, by New Year's Day, I _may_ have a _defendable_ BOE on how long the task will take, but there is a significant probability that I will not have executable code that generates a correct assembly file.

If someone else has already implemented something similar (or decided not to) and that project has shared lessons-learned, timelines, hiccoughs, anything, then that information could help me better communicate with my superordinates, perhaps manage their expectations, possibly add value to my implementation.

If a similar project took two years, then my superordinates might be happier with what I'm able to accomplish in six weeks. Of course if a similar project took six weeks, I'll have to resign in utter embarrassment--unless I can rapidly adapt their methods to my project's platform :-}

So, as much as I truly appreciate your suggestions on potential implementations, what I really need is information about projects that have _actually implemented_ (or chosen not to implement) an LLVM backend on a platform that has no stack. And I apologize again for not having been clear about that previously. In hind sight, I can immediately see that what I wrote was much too open and vague, not at all correct except when viewed through the filter of my personal assumptions.

Just for situational awareness, I found a PDF of a presentation (sub-)titled "Using LLVM to Generate FPGA Accelerators" by Altera, and I plan to digest it today, although a quick scan provided little hope. Searching the Altera (redirected to Intel) website on "LLVM" got no hits, reducing hope.

More thanks than I can type,
JD

-----Original Message-----
From: Anton Korobeynikov [mailto:anton at korobeynikov.info] 
Sent: Saturday, December 15, 2018 8:33 AM
To: jjones at prc-hsv.com
Cc: brucehoult at sifive.com; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] LLVM Backend for a platform with no (normal) stack

Well, since you're having memory, then things are more or less doable – all you need is to create and maintain stack by yourself. This could be done on per-function basis or whole program (the technique is called "compiled stack" or "software stack").
On Fri, Dec 14, 2018 at 11:09 PM JD Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Thanks, no malloc or free equivalents either (no heap).
>
>
>
> So, there are no others (to your knowledge) who have built an LLVM backend for a platform with no “normal” stack?  I found a presentation about some FPGA work (using LLVM) but it doesn’t seem to apply to my platform. Perhaps someone else on the mailing list will have come across this rarity?
>
>
>
> Thank you again for your time and responses. If I have inadvertently been rude, please forgive someone new to LLVM? And if your forgiveness stretches that far, perhaps you could clue me on just how I was rude so that I can avoid it in the future?
>
>
>
> More thanks,
>
> JD Jones
>
>
>
> From: Bruce Hoult [mailto:brucehoult at sifive.com]
> Sent: Friday, December 14, 2018 1:29 PM
> To: jjones at prc-hsv.com
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] LLVM Backend for a platform with no (normal) 
> stack
>
>
>
> Having your function prologue call malloc() and epilogue call free() (or similar functions) instead of bumping a stack pointer is not a problem. That stuff is generated explicitly by ISA-specific code anyway.
>
>
>
> On Fri, Dec 14, 2018 at 9:05 AM JD Jones <jjones at prc-hsv.com> wrote:
>
> Thanks for your response.  Please see below.
>
>
>
> From: Bruce Hoult [mailto:brucehoult at sifive.com]
> Sent: Thursday, December 13, 2018 5:58 PM
> To: jjones at prc-hsv.com
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] LLVM Backend for a platform with no (normal) 
> stack
>
>
>
> Do you have a register that you can store a memory address
>
> >> yes
>
>
>
> in and an addressing mode that allows you to add (or subtract) a 
> constant to that register
>
> >> Sometimes
>
>
>
> and use the address calculated to load//store from memory? Do you have enough registers that you can keep one of them permanently pointed to a particular memory region?
>
> >> No
>
>
>
> The platform intentionally does not allow use of some large chunk of memory for shared use by function calls.  I can allocate memory (so long as I know the necessary size before-hand). I can work around this issue, but if someone has already addressed it, I’d like to learn from their experiences before rolling my own.
>
>
>
> If yes, then you have a stack to exactly the same extent as RISC-V or MIPS do.
>
>
>
> On Thu, Dec 13, 2018 at 12:53 PM JD Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Dear Sir or Ma’am;
>
>
>
> I have found a wealth of help and information on writing an LLVM backend. And, my platform has no stack.
>
>
>
> Can you point me to any information that would specifically address creating a backend for this kind of platform?
>
>
>
> In previous wanderings, I thought I ran across a phrase “platforms with no stack such as FPGAs”, but I can’t find that mention, now.
>
>
>
> More thanks than I can type,
>
> JD Jones
>
> Software Engineer
>
>
> This message is intended for the addressee only and may contain 
> Paragon Research Corporation (PRC) confidential or privileged 
> information.  Use or distribution of such confidential information is 
> strictly prohibited without the prior written permission of PRC.  If 
> you have received this message in error, please contact the sender 
> immediately and delete the message and attachments from your 
> computer._______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> This message is intended for the addressee only and may contain Paragon Research Corporation (PRC) confidential or privileged information.  Use or distribution of such confidential information is strictly prohibited without the prior written permission of PRC.  If you have received this message in error, please contact the sender immediately and delete the message and attachments from your computer.
>
>
> This message is intended for the addressee only and may contain 
> Paragon Research Corporation (PRC) confidential or privileged 
> information.  Use or distribution of such confidential information is 
> strictly prohibited without the prior written permission of PRC.  If 
> you have received this message in error, please contact the sender 
> immediately and delete the message and attachments from your 
> computer._______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University


-- 
This message is intended for the addressee only and may contain Paragon 
Research Corporation (PRC) confidential or privileged information.  Use or 
distribution of such confidential information is strictly prohibited 
without the prior written permission of PRC.  If you have received this 
message in error, please contact the sender immediately and delete the 
message and attachments from your computer.