search for: mcassembl

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h @@ -669,7 +669,9 @@ public: - void Finish(); + /// \arg Writer is used for custom object writer (as the MCJIT does), + /// if not specified it is automatically crea...

...ionality, then submitting them to >>> llvm-commits for review. That is much easier for us to deal with than >>> large monolithic patches out of tree. >> >> Ok. Sorry for the too big patch. Attached is the first patch adding >> only 2 hooks on TargetMachine and on MCAssembler. Style should be LLVM >> compliant. Apply it with "patch -p0". > > +  // Make sure the code model is set. > +  setCodeModelForStatic(); > > For the JIT, this should be setCodeModelForJIT; it makes a difference > on, for example, x86-64.  I'd also suggest chan...

Dear llvm-dev, The attached patch fixes the following error when building LLVM with VS2005: lib\MC\MCAssembler.cpp(931) : error C2354: 'llvm::MCSymbolData::Symbol' : initialization of reference member requires a temporary variable Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090831/c...

...ut as Rafael pointed out to me over IRC the optimized path should be emitting object files. This WIP patch moves MCSymbolData into MCSymbol.h and makes it a field inside MCSymbol. This eliminates a pointer from MCSymbolData back to MCSymbol, the DenseMap<const MCSymbol *, MCSymbolData *> in MCAssembler, and converts the iplist in MCAssembler into a std::vector (along with some churn to pass around MCSymbols instead of MCSymbolData). As a result, during object emission we save ~6 pointers per MCSymbol, eliminate lookup indirection between MCSymbol and MCSymbolData, and avoid allocation overhead...

...gt; wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >> New patch taking Eli's comments into account. > > Comments inline.  If you have commit access, I'd fire away.  If not, I can. > > diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h > index 07ca070..afff96e 100644 > --- include/llvm/MC/MCAssembler.h > +++ include/llvm/MC/MCAssembler.h > @@ -669,7 +669,9 @@ public: > -  void Finish(); > +  /// \arg Writer is used for custom object writer (as the MCJIT does), > +  /// if not...

Big thanks, i've managed to find what's going on. The thing that dumbfolded me a couple of times was that the error was thrown in one of the MCAssembler methods, but never in applyFixup() itself. On Thu, Jan 19, 2017 at 8:46 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 10:21 AM, Peter Bel wrote: > >> Hi, >> >> For the function call - yes, probably. But what about branching inside >> on...

...T, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though. OK, I'm still experimenting with this. But it seems that I just need to modify the "FixedValue" parameter of the RecordRelocation method. More on this in future patches. :) > There seems to be an ownership problem of the...

...I(Triple::OSType OSType) { > switch (OSType) { > case Triple::FreeBSD: > @@ -52,6 +80,8 @@ public: > virtual void adjustFixupOffset(const MCFixup &Fixup, > uint64_t &RelocOffset); > > + virtual void ReorderRelocs(const MCAssembler &Asm, s/ReorderRelocs/reorderRelocs/. Function names start w/ a lower case letter. Personally, I prefer naming the prefix "sort" rather than "reorder", as it's a bit more descriptive, but not a big deal either way. > + std::vector<ELFRel...

...>>      switch (OSType) { >>        case Triple::FreeBSD: >> @@ -52,6 +80,8 @@ public: >>    virtual void adjustFixupOffset(const MCFixup &Fixup, >>                                   uint64_t &RelocOffset); >> >> +  virtual void ReorderRelocs(const MCAssembler &Asm, > s/ReorderRelocs/reorderRelocs/. Function names start w/ a lower case letter. Personally, I prefer naming the prefix "sort" rather than "reorder", as it's a bit more descriptive, but not a big deal either way. > >> +                          std::vec...

...Type) { >>> case Triple::FreeBSD: >>> @@ -52,6 +80,8 @@ public: >>> virtual void adjustFixupOffset(const MCFixup &Fixup, >>> uint64_t &RelocOffset); >>> >>> + virtual void ReorderRelocs(const MCAssembler &Asm, >> s/ReorderRelocs/reorderRelocs/. Function names start w/ a lower case letter. Personally, I prefer naming the prefix "sort" rather than "reorder", as it's a bit more descriptive, but not a big deal either way. >> >>> +...

...t;. The MCJIT can now execute little functions with no relocation (like add(a,b) => a+b), to do that some modifications have been made : - The addPassesToEmitMC method has been added to TargetMachine class. It fills the MCContext pointer so we can build the MCJITStreamer. - The Finish method of MCAssembler have a new optional argument "Writer" to allow a custom MCJITObjectWriter to be used. Can you give us some feedbacks on the general idea and on this 2 particular hooks ? Currently MCJIT has one unittest and the binary size is quite big (~110MB in debug...) because before using the MC...

...ow execute little functions with no relocation (like > add(a,b) => a+b), to do that some modifications have been made : > - The addPassesToEmitMC method has been added to TargetMachine class. > It fills the MCContext pointer so we can build the MCJITStreamer. > - The Finish method of MCAssembler have a new optional argument > "Writer" to allow a custom MCJITObjectWriter to be used. > > Can you give us some feedbacks on the general idea and on this 2 > particular hooks ? > > > Currently MCJIT has one unittest and the binary size is quite big > (~110MB in...

...t's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by " EF.getHeader()->e_machine" but I found "e_machine" is defined somewhere in MCAssembler(My compiler uses binutils as assembler) . Although I make some hacks to pass this checking, I still get other errors. So my problem is whether llvm-cov has to work with MCAssembler and is it possible to do it with binutils? Best, Ruobin > -----邮件原件----- > 发件人: vsk at apple.com [mailto:vsk...

..." that is > "Fixed up" after all the blobs that go into that subsection are > emitted? The closest examples I could find weren't that close :-( > (Matter of fact, for ELF, it looks like the section sizes are actually > calculated after everything has been processed by MCAssembler, and the > headers sizes are not "fixed up" but completely rewritten from the > beginning) I really don't follow. Please just convert the current patch to use the existing APIs. If in the next one you really need a missing feature it will be a lot easier to explain what it is...

...ips and am trying to not > hack the code. > > I how exactly does one set an expression to be PC relative and if the > compiler can resolve it, not produce a relocation? > Fixups are created for all expressions that may need a relocation. The MC layer evaluates them as best it can (MCAssembler::EvaluateFixup()) and calls the target hook RecordRelocation() if it cannot evaluate it directly and needs a relocation in the object file. > In our case, the backend produces an expression for the branch which is > the target label. I make a call from the .td for the branch instruction &...

Hi, For the function call - yes, probably. But what about branching inside one function (standard if-then for example)? For example: echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x c - -o /tmp/a.o -c && objdump -d /tmp/a.o Thanks, Petr On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 9:11

...notes: > -- >> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >> index 2cf65c1..02ac2be 100644 >> --- a/lib/Target/X86/X86AsmBackend.cpp >> +++ b/lib/Target/X86/X86AsmBackend.cpp >> @@ -14,6 +14,7 @@ >>  #include "llvm/MC/MCAssembler.h" >>  #include "llvm/MC/MCExpr.h" >>  #include "llvm/MC/MCObjectWriter.h" >> +#include "llvm/MC/MCSectionCOFF.h" >>  #include "llvm/MC/MCSectionELF.h" >>  #include "llvm/MC/MCSectionMachO.h" >>  #include &...

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

...It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by " EF.getHeader()->e_machine" but I found "e_machine" is defined somewhere in MCAssembler I haven’t double-checked, but I thought this definition came from llvm/Support/ELF.h? (My compiler uses binutils as assembler) . Although I make some hacks to pass this checking, I still get other errors. So my problem is whether llvm-cov has to work with MCAssembler and is it possible to do...

Some more information about the relaxation pass whose effectiveness and convergence guarantees were listed as a concern: TLDR; Our relaxation pass is similar to what LLVM’s MCAssembler does but with a caveat for efficiency. Our experimental results show it is efficient and convergence is guaranteed. Our relaxation pass is very similar to what MCAssembler does as it needs to solve the same problem, which is laying out basic blocks and optimizing branch instruction sizes based...