search for: mccontexts

Displaying 20 results from an estimated 79 matches for "mccontexts".

Did you mean: mccontext
2013 May 23
4
[LLVMdev] Usage of getenv() inside LLVM and thread safety
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
2013 Nov 12
3
[LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"
On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > Hi Manman, > > Thanks for sending this summary and progress plans - it's great to see the > impact your changes have had and ideas for future direction. > > Type uniquing for C++ is in. Some data for Xalan with -flto -g: >> 9.9MB raw dwarf size, peak memory usage at 2.8GB >> The
2011 Aug 29
0
[LLVMdev] PTX target for LLVM!
Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor
2010 Jul 21
0
[LLVMdev] MC-JIT
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
2010 Apr 27
5
[LLVMdev] PTX target for LLVM!
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,
2010 Jul 20
2
[LLVMdev] MC-JIT
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
2010 Jul 28
3
[LLVMdev] Function-at-a-time Processing
...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 b...
2013 May 23
2
[LLVMdev] Usage of getenv() inside LLVM and thread safety
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
2011 Sep 08
0
[LLVMdev] [LLVM, llvm-mc, AsmParser] Symbol locations.
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
2013 Nov 12
0
[LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"
On Tue, Nov 12, 2013 at 2:08 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Nov 12, 2013 at 1:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> Hi Manman, >> >> Thanks for sending this summary and progress plans - it's great to see >> the impact your changes have had and ideas for future direction. >> >>
2013 May 23
0
[LLVMdev] Usage of getenv() inside LLVM and thread safety
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
2011 Sep 08
2
[LLVMdev] [LLVM, llvm-mc, AsmParser] Symbol locations.
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
2013 May 23
0
[LLVMdev] Usage of getenv() inside LLVM and thread safety
Right. glibc's amusing stance is that you setenv/putenv are not thread safe, but getenv is. I assume Ruby exposes setenv and therefore simply not calling setenv isn't an option. Would it solve your problems if all getenv() calls happened at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > >
2010 Jul 21
1
[LLVMdev] MC-JIT
New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>
2010 Jul 28
0
[LLVMdev] Function-at-a-time Processing
...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 fu...
2020 Nov 12
0
Supporting external MCContext in MMI
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
2013 Nov 12
3
[LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"
Hi All, Type uniquing for C++ is in. Some data for Xalan with -flto -g: 9.9MB raw dwarf size, peak memory usage at 2.8GB The raw dwarf size was 58MB, 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
2013 Nov 12
0
[LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"
Hi Manman, Thanks for sending this summary and progress plans - it's great to see the impact your changes have had and ideas for future direction. Type uniquing for C++ is in. Some data for Xalan with -flto -g: > 9.9MB raw dwarf size, peak memory usage at 2.8GB > The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. > Other efforts at size reduction helped, and type
2020 Feb 04
3
Reporting source errors from MCCodeEmitter::encodeInstruction() ?
[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
2019 Oct 16
2
[cfe-dev] [Openmp-dev] RFC: End-to-end testing
On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Renato Golin via Openmp-dev <openmp-dev at lists.llvm.org> writes: > > > But if we have some consensus on doing a clean job, then I would > > actually like to have that kind of intermediary check (diagnostics, > > warnings, etc) on most test-suite tests, which would