similar to: [LLVMdev] Extending Backends in LLVM-based projects

> > LLVA specifically is refering to a research project offshoot of llvm. > > LLVM instructions do not have 1:1 mappings to native instructions > > (sometimes multiple llvm instructions map to fewer native insts, > > sometimes the other way around). > > That's correct, and furthermore, LLVA (now called SVA = Secure > Virtual Architecture) uses essentially the

On 4/2/07, Fabian Scheler <fabian.scheler at gmail.com> wrote: > Hello everybody, > > I'm curious whether there have been any attempts to perform > performance analysis on the LLVA level. I am interested in the > derivation of flow-facts (loop bounds etc. - what about the > value-range-propagation pass I read about on this list some time ago) > but even more I am

On Apr 3, 2007, at 10:55 AM, Andrew Lenharth wrote: > On 4/2/07, Fabian Scheler <fabian.scheler at gmail.com> wrote: >> Hello everybody, >> >> I'm curious whether there have been any attempts to perform >> performance analysis on the LLVA level. I am interested in the >> derivation of flow-facts (loop bounds etc. - what about the >>

Hello everybody, I'm curious whether there have been any attempts to perform performance analysis on the LLVA level. I am interested in the derivation of flow-facts (loop bounds etc. - what about the value-range-propagation pass I read about on this list some time ago) but even more I am interested in exec-time modeling (how long does it take to execute a bunch of LLVA instructions on

On Fri, 10 Aug 2007, David Greene wrote: > I'm looking at extending AsmPrinter to pretty-print comments after > instructions (I'm adding the necessary fields to MachineInstr to do this). ok > I also have a few questions on the general design of AsmPrinter. Why is > runOnMachineFunction implemented for each target AsmPrinter? I would Historical reasons that aren't very

I'm looking at extending AsmPrinter to pretty-print comments after instructions (I'm adding the necessary fields to MachineInstr to do this). I'm trying to grok AsmWriterEmitter and having a tough go of it. I look at X86GenAsmWriter1.inc (the Intel syntax writer) and understand that there's a case block for printing operands under several switch statements, one per

On Monday 13 August 2007 15:50, Chris Lattner wrote: > > I also have a few questions on the general design of AsmPrinter. Why is > > runOnMachineFunction implemented for each target AsmPrinter? I would > > Historical reasons that aren't very good. Over the years, I've taken > several stabs at merging the asmprinters from various targets together. > They used to

Hi, community: For the sake of our business need, I want to enable "Function-based parallel code generation" to boost up the compilation of single module, please see the details of the design and provide your feedbacks on below aspects, thanks 1. Is this idea the proper solution for my requirement 2. This new feature will be enabled by llc -thd=N and has no impact on

I work on the LLILC team, and we are trying to send debug line info through to the CoreCLR EE without using an EventListener because we need to send extra info (more than just available in DebugLoc) like if it’s a call instruction, a call site, etc. We thought extending AsmPrinterHandler would be useful since it seems to have information about debug locations, label offsets, and instruction

On Wed, 2007-08-15 at 09:32 -0700, Chris Lattner wrote: > On Tue, 14 Aug 2007, David Greene wrote: > >> Yes, this is one advantage, another is that we wouldn't have to fix the > >> same bug in multiple places :) > > > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > > given the current design. > > Ok, cool. >

On Tue, 14 Aug 2007, David Greene wrote: >> Yes, this is one advantage, another is that we wouldn't have to fix the >> same bug in multiple places :) > > Right. I've figured out where I need to make the changes in AsmWriterEmitter > given the current design. Ok, cool. > I'm trying out a few interesting things here based on custom streambufs. > It requires

On Wednesday 15 August 2007 11:32, Chris Lattner wrote: > > I'm trying out a few interesting things here based on custom streambufs. > > It requires some surgery to AsmPrinters as a std::ostream won't work > > anymore due to the enhanced functionality of the custom streambufs. > > Is this still interesting to the larger LLVM community? One thing I have > >

On Mar 13, 2010, at 11:54 AM, James Stanier wrote: > It > analyses the CFG and recognises specific region schema, such as if- > then, > if-then-else, while-loop, etc., and builds a "control tree" which > represents > the hierarchical structure of the input program. I am not sure if my definition of a control flow tree is the same as yours, but if it is, I am very

> Patch committed here: Just looked at the WebCVS. > I made a couple of changes to the code you submitted. The most important > is that I converted this (in the .h files): > > using namespace llvm; > namespace x86 { > ... > > into: > > namespace llvm { > namespace x86 { > ... Right, that is how I had it in the beggining, obviously I miss understood your

On Sat, 2 Jul 2005, Aaron Gray wrote: >>> The only thing I did not like was a clsh between the enum X86 and the new >>> namespace X86, which I had to rename as x86 :( >>> >>> Anyway, I suppose the lower case 'x' in 'x86' fits in with the lowercase >>> 'llvm' namespace. >> >> I'm not sure I follow. X86 is a

Dear all, I am currently working on a function in which I would like to avoid using the command sample(). Therefore, I am now trying to make a for loop that does the same thing as the in built function sample does: Rearranging the items of a object randomly. So, the output I want to you get is the same as sample() would give me: e.g.: data <- c(5,4,6,7,8) sample(data) > data <-

> -----Original Message----- > From: Fabian Scheler [mailto:fabian.scheler at gmail.com] > Sent: Thursday, August 16, 2012 4:58 AM > To: LLVM Developers Mailing List; Villmow, Micah > Cc: Stellard, Thomas; cameron.mcinally at nyu.edu > Subject: Re: [LLVMdev] More Back-End Porting Troubles > > Hi, > > first of all: thanks for your kind, very helpful and unbelievable

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday, August 15, 2012 9:12 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] More Back-End Porting Troubles > > Hi LLVM-Folks, > > as mentioned in an earlier post >

(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number field. We could stash the extra bits in the column info but that’s starting to

On Wednesday 15 August 2007 13:10, Reid Spencer wrote: > > It really depends on what you mean. I've found that iostreams are > > extremely slow, much slower than C stdio streams. Eventually I'd like to > > move them to stdio, not to more complex streambufs :) > > Eventually I'd like to move them to native syscalls adapted by > lib/System and suited to the