search for: mccontext

Hello, In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")). The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around the getenv() calls we do in Rubinius, but that's real...

...bout > the design impact it will have on existing and future work (it's already > going to substantially change the cross-CU-DIE references, potentially > changing the cost/benefit of that feature since we cannot inject DIEs from > later CUs into prior ones). > > >> 4G MCContext >> > > What's the data in the MCContext that's relevant to debug info? > One data point on "Xalan": without -g, MCContext allocates 45MB, with -g, MCContext allocates 286MB. > > >> --> The memory usage is still too big. >> > > Do we...

...tAddressSpace(const llvm::Value*)’: PTXBackend.h:556:40: error: ‘const class llvm::Value’ has no member named ‘getUnderlyingObject’ PTXBackend.cpp: In member function ‘virtual bool PTXWriter::doInitialization(llvm::Module&)’: PTXBackend.cpp:432:29: error: no matching function for call to ‘llvm::MCContext::MCContext(const llvm::MCAsmInfo&)’ /home/neelima/Documents/llvm-2.9/include/llvm/MC/MCContext.h:105:14: note: candidates are: llvm::MCContext::MCContext(const llvm::MCAsmInfo&, const llvm::TargetAsmInfo*) /home/neelima/Documents/llvm-2.9/include/llvm/MC/MCContext.h:40:5: note:...

...e here, but there should be for consistency. The comment below should look like the rest of the Doxygen comments: /// methodName - Use complete sentences starting with caps and ending with /// periods. + /// get machine code emitted. This method should returns true if fails. + /// It fills the MCContext Ctx pointer used to build MCStreamer. + /// + virtual bool addPassesToEmitMC(PassManagerBase &PM, + MCContext *&Ctx, + CodeGenOpt::Level OptLevel, + bool DisableVerify = true) { + return tru...

Hey everybody, good news for everyone interested in the PTX backend: We decided to release the current source code under the GPL - you can find the latest tarball here: http://www.prog.uni-saarland.de/projects/anysl You will find the README in the attachment, which should hopefully answer a lot of questions concerning the implementation and the current status. If you have further questions,

New patch taking Eli's comments into account. Olivier. On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >>> Seems reasonable, but I haven't looked at the code yet. I would >>> suggest trying to split your work up into separate

...the module pass manager to dump out the stuff needed at the end of the asm file. This was not at all pretty but I could at least get it to work. I'm in the last stages of upgrading to LLVM 2.7 and I'm finding that the new MCStreamer system is making this sort of model much more difficult. MCContexts are somehow shared between the separate module and function pass managers in ways I don't understand. I think that somehow the LLVMTargetMachine is shared between the pass managers. I think this sort of sharing is actually correct since we want the MCContext for the function pass manager to...

On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > That sounds like a missed multi-threading issue with LLVM. I can't > imagine why the user should be forced to serialize creation of MCContext > objects. I would suggest filing a bug for this. A simple lock probably > wouldn't be too detrimental to performance here, since MCContext objects > shouldn't be created too often. > > The deeper question is why we are even checking a "global" here in the first pl...

Now I see, that its to so trivial as I thought before. There are a lots of parser extensions that creates the symbols. And in each place we need insert add its location info. I also found that MCContext has several create symbols methods, but all these methods uses CreateSymbol private method. So I see two possible ways here: 1. To aggregate all GetOrCreate-like symbol methods inside the AsmParser. So all asm parser extension like a COFFAsmParser should use aggregated methods instead of MCContext...

...act it will have on existing and future work (it's already >> going to substantially change the cross-CU-DIE references, potentially >> changing the cost/benefit of that feature since we cannot inject DIEs from >> later CUs into prior ones). >> >> >>> 4G MCContext >>> >> >> What's the data in the MCContext that's relevant to debug info? >> > > One data point on "Xalan": > without -g, MCContext allocates 45MB, > with -g, MCContext allocates 286MB. > OK, might be useful to understand which parts of t...

That sounds like a missed multi-threading issue with LLVM. I can't imagine why the user should be forced to serialize creation of MCContext objects. I would suggest filing a bug for this. A simple lock probably wouldn't be too detrimental to performance here, since MCContext objects shouldn't be created too often. On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > > In...

Hi everybody. I found that there are some problems with symbol location in AsmParser. 1. We need to know where symbol was declared. 2. We need to know where symbol was defined first time. There are two ways: 1. Add helper table to the parser with additional symbol info. But it takes additional memory consumption. 2. Add user tag (void*) for MCSymbol object. As I understood MCSymbol can live

...at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > > In Rubinius we're seeing an occasional crash inside LLVM that always > happens inside getenv(), which is used for example when creating a > MCContext (inside lib/MC/MCContext.cpp, it checks > getenv("AS_SECURE_LOG_FILE")). > > The problem is that getenv() and friends aren't thread safe and Rubinius > provides a multithreaded system. We can relatively easily get locking setup > around the getenv() calls we do in Rubin...

...or consistency.  The comment > below should look like the rest of the Doxygen comments: > /// methodName - Use complete sentences starting with caps and ending with > /// periods. > > +  /// get machine code emitted.  This method should returns true if fails. > +  /// It fills the MCContext Ctx pointer used to build MCStreamer. > +  /// > +  virtual bool addPassesToEmitMC(PassManagerBase &PM, > +                                 MCContext *&Ctx, > +                                 CodeGenOpt::Level OptLevel, > +                                 bool DisableVerify...

...ut the stuff needed at the end of the asm > file. > > This was not at all pretty but I could at least get it to work. > > I'm in the last stages of upgrading to LLVM 2.7 and I'm finding that the > new MCStreamer system is making this sort of model much more difficult. > MCContexts are somehow shared between the separate module and function > pass managers in ways I don't understand. I think that somehow the > LLVMTargetMachine is shared between the pass managers. > > I think this sort of sharing is actually correct since we want the > MCContext for the f...

Hi we have something like an external driver that likes to own MCInst data externally, i.e. outside from LLVM. By default, the MachineModuleInfo/WrapperPass creates its own context in the constructor of MachineModuleInfo. MMI's context is used throughout codegen. When using a MCStreamer with an external context one can achieve almost what we want, because the streamer's context is used to

...MB, memory usage was 7GB back in May, 2013. Other efforts at size reduction helped, and type uniquing improved on top of those. Data on building clang with "-flto -g" after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB MDNodes after linking all bc files 4.6GB DIEs 4G MCContext --> The memory usage is still too big. So how to reduce the memory footprint at MDNode level: 1> Combine integers into MDString and further combining MDStrings (see PR17891) A partial implementation on the important debug info nodes can reduce the MDNodes from 7GB to 5.7GB 2>...

...han later as I'm concerned about the design impact it will have on existing and future work (it's already going to substantially change the cross-CU-DIE references, potentially changing the cost/benefit of that feature since we cannot inject DIEs from later CUs into prior ones). > 4G MCContext > What's the data in the MCContext that's relevant to debug info? > --> The memory usage is still too big. > Do we have an idea of what size is "small enough"? It would be useful to have a goal. > So how to reduce the memory footprint at MDNode level: >...

[apologies for this duplicate post: originally sent to lldb-dev by not paying attention to the address auto-completion] We have a backend for a target that at present only detects some assembler errors when emitting instructions (basically because the platform has configurable properties with dependencies between instructions and it was easier to check for their interaction late than try to

...to the direction suggested by others that the monorepo is orthogonal to this issue and top level tests might not be the right thing. lldb already does end-to-end testing in its tests, for instance. Clang does in some tests (the place I always hit is anything that's configured API-wise on the MCContext - there's no way to test that configuration on the clang boundary, so the only test that we can write is one that tests the effect of that API/programmatic configuration done by clang to the MCContext (function sections, for instance) - in some cases I've just skipped the testing, in others...