similar to: Two FPPassManager objects, and LocalStackSlotAllocation::runOnMachineFunction returns true but has not changed the data

For a machine like an FPGA with no stack, you have to ensure that you have an optimization that rewrites the alloca into either registers (such as PromoteMem2Reg) or that you rewrite the alloca by declaring a static local, and rewriting the code to use that instead of the alloca result. Mark Mendell From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Bruce Hoult 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

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

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

If _<lowerCaseLetter> violates a standard, please say which one. It does not violate the C++11 standard: •Reserved in any scope, including for use as implementation macros: •identifiers beginning with an underscore followed immediately by an uppercase letter •identifiers containing adjacent underscores (or "double underscore") •Reserved in the global namespace: •identifiers

Hi Tim, Sorry, I'm not sure I follow. Are you maybe thinking that if the identifiers were tagged to specify scope, people would still be trying to use acronyms or single letters? So that, what in future code might be F, would instead be _f and that would be worse than f_ or s_f? I was thinking instead F would be (for new or modified code) _function or _fnctn or _func (as an object of type

If we're talking about member variables, just put an m in front of it, problem solved. You already have one for s_, and I didn't see you mention it but I assume you'd want g_ for globals, so m_ makes perfect sense for member variables and there's no question about UB at that point. On Mon, Feb 4, 2019 at 1:27 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.

I so agree. I have found scope based coding conventions very useful. My favorite was: * Static data member: s_<lowerCaseLetterThenCamelCase> * Non-static data members: _<lowerCaseLetterThenCamelCase> (This was allowed by the C++ standard I last read. It’s _<UpperCase> that is reserved) * Function argments:

On 2/4/2019 2:29 PM, Tim Northover via llvm-dev wrote: > On Mon, 4 Feb 2019 at 20:21, JD Jones <jjones at prc-hsv.com> wrote: >> If _<lowerCaseLetter> violates a standard, please say which one. It does not violate the C++11 standard: > > If strictly adhered to, it doesn't, and I've never claimed any > different. But coding standards are never strictly adhered

This sounds similar to what the LocalStackSlotAllocation pass does (lib/CodeGen/LocalStackSlotAllocation.cpp). -Jim On Feb 7, 2013, at 4:56 PM, reed kotler <rkotler at mips.com> wrote: > There is an optimization which the Greenhills compiler does for mips16. > > I have not looked at it myself ,but it was recounted to me. > > The basic idea is that if you have a large

On 02/07/2013 05:28 PM, Jim Grosbach wrote: > This sounds similar to what the LocalStackSlotAllocation pass does (lib/CodeGen/LocalStackSlotAllocation.cpp). > > -Jim exactly but this is for structs but maybe you are saying that i can reuse those ideas for structs. i'm going to turn on the localstackallocation soon . maybe i need to study that and write something similar for plain

Not only do FPGAs not support recursion, we don’t even support calls! All user code must be inlined into one kernel/component, which is then used to create HDL for the FPGA. Mark From: Bruce Hoult <brucehoult at sifive.com> Sent: December 17, 2018 9:28 AM To: Mendell, Mark P <mark.p.mendell at intel.com> Cc: jjones at prc-hsv.com; LLVM Developers Mailing List <llvm-dev at

Hi, It seems to me that the TwoAddressInstructionPass::runOnMachineFunction method has some problems when the tied destination register has a subReg. The two changes below improves the situation for me but I'm all new to this so I'm not sure how it's supposed to work. I'm running on 2.9. Any comments? @@ -1172,12 +1172,20 @@ bool

> Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. I have encountered very long compile times for three large source files containing generated/unrolled code at -O1. We are talking about 10+ hours here without completing, so it looks very much like an endless loop. The

I know this has come up before....but.. I've got a locking issue I can't get over. Situation: --------- Unix writes a file to the /tmp directory MS-DOS (WFW 3.11) copys over the file (copy d:\file.txt ), locking it, and not releasing the lock. If Unix subsequently changes the file a re-issuing of the MS-DOS 'copy' command will appear to work ... but the MS-DOS file is

Hi again, Kind people on #llvm helped me to utilize bugpoint to reduce the previously submitted test case. For record, it code be done with the following command: $ bugpoint -llc-safe test.ll The resulting IR is attached, and it is crashing in the same way. Is it a valid code? dmikushin at hp2:~/forge/kernelgen/branches/tests_lnt/behavior/sincos> llc test.ll.1 This action is not supported

Hi, After building out project in release mode, caught an assertion, which we have not seen before: hello_f: /tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/ADT/DenseMap.h:126: void llvm::DenseMap<KeyT, ValueT, KeyInfoT>::clear() [with KeyT = llvm::MachineBasicBlock*, ValueT = <unnamed>::BlockChain*, KeyInfoT = llvm::DenseMapInfo<llvm::MachineBasicBlock*>]: Assertion

Dear NVPTX community, I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with reprocase for this issue. Please, help us to fix it. Last 1,5 months we regularly encounter & workaround or fix 1-2 bugs per week in NVPTX backend. This is definitely not the amount of work we can completely serve ourselves... We would really really appreciate some collaboration. Thanks, - D.

Hi, I'm trying to use llvm/clang to cross compile to sparcv9. The following works with a -march=sparc, but yields errors for sparcv9. Are there some other flags that need to be specified? Thanks, Tarun > clang -m64 -emit-llvm test.c -c -o test.bc > llc -march=sparcv9 test.bc -o hello.s ExpandIntegerResult #0: 0x8a6c478: i64 = GlobalAddress<[4 x i8]* @.str> 0 [ORD=1] [ID=0] Do