similar to: [LLVMdev] Proposal: Splitting up MC/ELF + AsmPrinter Hierarchy?

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

On Thu, Oct 21, 2010 at 7:50 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Hmm, I wish we had this discussion way earlier.. >> >> How would I emit things in different subsections? I can do a high >> level switch to .ARM.attributes, and if I were emitting one blob from >> begin to end, using the higher level interface would be preferable,

> Also what is the preferred method for MC way of setting out subsection > sizes after the fact? I am guessing I need to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >>

Hi, I have a question about the memory dependence analysis. I am trying to use it to selectively enumerate a set of pairs of (load, store) instructions for every function by calling getNonLocalDependency() on the MemoryDependenceAnalysis. This populates a DenseMap<BasicBlock*, Value*>. I just looked up an usage of this in GVN.cpp: MD->getNonLocalDependency(C, deps); for

Hi, MemDep caches results for local queries and provides means to invalidate them by keeping reverse maps. Unfortunately, it also caches results that represent non-local dependencies, for which there are no reverse map entries, and thus those entries can not be invalidated. This is a problem when an optimization turns a non-local dependency into a local one.

On Jul 28, 2008, at 3:47 PM, Prakash Prabhu wrote: > Hi, > > I have a question about the memory dependence analysis. I am trying > to use it to selectively enumerate a set of pairs of (load, store) > instructions for every function by calling getNonLocalDependency() > on the MemoryDependenceAnalysis. This populates a > DenseMap<BasicBlock*, Value*>. I just

---------- Forwarded message ---------- From: Jason Kim <jasonwkim at google.com> Date: Fri, Oct 22, 2010 at 12:59 PM Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes To: Rafael Espíndola <rafael.espindola at gmail.com> On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Oct 21,

On Sun, 04 May 2008 16:05:44 +0000, Hendrik Boom wrote: > The languages I'm faced with compiling in the near future have nonlocal > go to statements and nested procedures. > > A procedure gets implemented as a structure containing its entry point > and an environment pointer. It is easy enough to call its entry point > and pass the environment pointer as an extra argument

On May 4, 2008, at 9:05 AM, Hendrik Boom wrote: > The languages I'm faced with compiling in the near future have > nonlocal goto statements and nested procedures. You want to return to a previous activation record (pascal speak) or stack frame? If yes, then yes, EH will do that for you. You'll want to understand what EH is in detail and how to map the semantics you want

The languages I'm faced with compiling in the near future have nonlocal go to statements and nested procedures. A procedure gets implemented as a structure containing its entry point and an environment pointer. It is easy enough to call its entry point and pass the environment pointer as an extra argument (rather like the pointer to this or self in object-oriented code). It's no

On Mon, 05 May 2008 09:56:26 +0200, Duncan Sands wrote: > Hi, > >> The problem is with the go to statement. Again, local go to's, that go >> somewhere within the same function are no particular problem -- though >> I haven't studied the interaction with alloca yet; that might offer a >> few surprises. The questions I have are about goto's that exit

Hi, > The problem is with the go to statement. Again, local go to's, that go > somewhere within the same function are no particular problem -- though I > haven't studied the interaction with alloca yet; that might offer a few > surprises. The questions I have are about goto's that exit from a > function. The traditional mechanism is to implement a label as an

Thanks for the quick reply, Owen. I went through the code in MemoryDependenceAnalysis.cpp again. Since DenseMap<BasicBlock*, Value*> maps a BasicBlock to a single Value (Instruction) and it is populated by a DFS on the reverse Control Flow Graph starting at the query instruction's block, is it correct to say that the last dependent instruction in each visited basic block is what is

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

The attached patch moves the ExtWeakSymbols to the AsmPrinter class and the code that emits the ".weak" directives to AsmPrinter::doFinalization. This is just code factoring. No functionality changes. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-patch Size: 5387 bytes Desc: not available URL:

On Sat, 9 Dec 2006, [UTF-8] Rafael Esp?ndola wrote: > The attached patch moves the ExtWeakSymbols to the AsmPrinter class > and the code that emits the ".weak" directives to > AsmPrinter::doFinalization. > > This is just code factoring. No functionality changes. Looks good, one request though: if practical, it would be nice to switch this to be set<GlobalValue*>

> Looks good, one request though: if practical, it would be nice to switch > this to be set<GlobalValue*> instead of set<std::string>. Attached > -Chris Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: text/x-patch Size: 7646 bytes Desc: not available URL:

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