similar to: [LLVMdev] Getting rid of tabs in LLVM's assembly output?

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Eli Bendersky > Subject: [LLVMdev] Getting rid of tabs in LLVM's assembly output? > Problem: I then get tabs in my tests, which are discouraged by LLVM's > own code standards, because assembly output uses tabs extensively. > Proposal: get rid of tabs by just replacing them with

On Tue, Dec 18, 2012 at 11:36 AM, Caldarale, Charles R <Chuck.Caldarale at unisys.com> wrote: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Eli Bendersky >> Subject: [LLVMdev] Getting rid of tabs in LLVM's assembly output? > >> Problem: I then get tabs in my tests, which are discouraged by LLVM's >>

On Dec 18, 2012, at 11:36 AM, "Caldarale, Charles R" <Chuck.Caldarale at unisys.com> wrote: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Eli Bendersky >> Subject: [LLVMdev] Getting rid of tabs in LLVM's assembly output? > >> Problem: I then get tabs in my tests, which are discouraged by LLVM's

But its pretty easy to change the tabstop within the editor to make it readable. On Tue, Dec 18, 2012 at 1:01 PM, Eli Bendersky <eliben at google.com> wrote: > On Tue, Dec 18, 2012 at 11:36 AM, Caldarale, Charles R > <Chuck.Caldarale at unisys.com> wrote: > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > >> On Behalf Of Eli

On Dec 18, 2012, at 2:07 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Dec 18, 2012 at 1:13 PM, Eli Bendersky <eliben at google.com> wrote: > On Tue, Dec 18, 2012 at 1:09 PM, Craig Topper <craig.topper at gmail.com> wrote: > > But its pretty easy to change the tabstop within the editor to make it > > readable. > > > > True, in

On Tue, Dec 18, 2012 at 1:09 PM, Craig Topper <craig.topper at gmail.com> wrote: > But its pretty easy to change the tabstop within the editor to make it > readable. > True, in this case... The output is not trying to be intelligent in the general case, just spitting out tabs. I agree that to replace this, however, it would be best to look at some smart column-padded formatting

On Tue, Dec 18, 2012 at 1:13 PM, Eli Bendersky <eliben at google.com> wrote: > On Tue, Dec 18, 2012 at 1:09 PM, Craig Topper <craig.topper at gmail.com> > wrote: > > But its pretty easy to change the tabstop within the editor to make it > > readable. > > > > True, in this case... The output is not trying to be intelligent in > the general case, just

> > Maybe it's naive, but I would expect it to be easy for each backend to > > expose a constant N which is the length of the longest mnemonic, and then > > for the printer to pad to N+1 or N+2…. > > That would probably work for X86, but other targets (ARM in particular) > often have operands which are printed/parsed as suffices on the mnemonic > itself. Because

On Dec 18, 2012, at 3:39 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Dec 18, 2012 at 3:36 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > > Maybe it's naive, but I would expect it to be easy for each backend to > > > expose a constant N which is the length of the longest mnemonic, and then > > > for the printer to pad to

On Tue, Dec 18, 2012 at 3:36 PM, Tim Northover <t.p.northover at gmail.com>wrote: > > > Maybe it's naive, but I would expect it to be easy for each backend to > > > expose a constant N which is the length of the longest mnemonic, and > then > > > for the printer to pad to N+1 or N+2…. > > > > That would probably work for X86, but other targets

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Kaylor, Andrew > Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines > If the function is in a statically linked module, you need to do something to explicitly expose it. With > the older JIT engine you can use addGlobalMapping as Yaron suggests, but I

That seems to work, thanks! The specific code I ended up with to call int64_t print(int64_t) looks like: auto f = builder.CreateIntToPtr( ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)), PointerType::getUnqual(FunctionType::get( builder.getInt64Ty(), {builder.getInt64Ty()}, false))); return builder.CreateCall(f, args); On Mon, Mar

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Kuperstein, Michael M via llvm-dev > Subject: Re: [llvm-dev] Test Email - Apologies for the noise > I'm seeing the same issue here, also with Outlook. > Had to CC the list manually for this email) Same problem here - good to know it's not just me. For reference, I'm using Outlook version

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of David Chisnall > Subject: Re: [LLVMdev] Publication: Languages Used in LLVM During Compilation > How do I download it? The link sends me to a site with ads, then when I > find the little English icon, there's a download link that takes me to a > page with a picture telling me an

On Wed, Mar 19, 2014 at 6:18 PM, Bryan Keiren < bryan.keiren at guerrilla-games.com> wrote: > We are indeed trying to completely clean the heap before exiting main(). > Which means that you either don't have threads, or you join all threads before main exits. Is that the case? Good for you if so! > > > -----Original Message----- > From: Caldarale, Charles R

> From: Armin Steinhoff [mailto:armin at steinhoff.de] > Subject: Re: [LLVMdev] New JIT APIs > is >  delete EE;   // execution engine >  llvm_shutdown(); > sufficient ? AFAICT, llvm_shutdown() must not be called unless you reach a point where LLVM will not be used again by the process (e.g., termination), as it destroys statically allocated objects. We delete the

Seems that Vijay is asking about converting C program to LLVM IR On Mon, Jul 29, 2013 at 9:26 PM, Eli Bendersky <eliben at google.com> wrote: > > > > On Sat, Jul 27, 2013 at 9:02 AM, Vijay Daultani <vijay.daultani at gmail.com>wrote: > >> Respected Sir/Madam, >> >> As I was developing some part of compiler for a project. I require grammar >>

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > Subject: Re: [LLVMdev] What would cause instructions to NOT make it into the module? > It is a pass that can be run like any other pass. See createVerifierPass(). You can also just call verifyModule() with the appropriate parameters; it's defined in

The option we use is to have a custom memory manager, override the getPointerToNamedFunction function, and provide the pointer to the external function at link time. The inttoptr scheme works fairly well, but it does make for some pretty ugly and sometimes hard to analyze IR. I recommend leaving everything symbolic until link time if you can. Philip On 03/28/2016 06:33 PM, Russell Wallace

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Bryan Keiren > Subject: [LLVMdev] getElapsedWallTime unnecessary heap allocation and memory leak > In the file \lib\Support\Process.cpp on line 60, it seems as though an > unnecessary heap allocation and memory leak occurs. > static TimeValue getElapsedWallTime() { >  static