search for: mapvalue

...xpected all forward declarations to be resolved"), function resolveCycles, file /Users/kfischer/julia/deps/llvm-svn/lib/IR/Metadata.cpp, line 459. > > because we still have the temporary DISubprogram in there. > > Any ideas what to do about this? > The logic I have between `MapValue(Metadata*)` and `MapValueImpl(Metadata*)` was supposed to solve this. (Actually, those names are awful, I may try to change them to `MapMetadata()`.) The logical flow should be: - MapValue(Metadata*) calls MapValueImpl(). - MapValueImpl() introduces a temporary. - MapValueImpl() recursivel...

Hello all When using llvm-ld to link several bitcode files produced by LLVM-GCC, I ran into the problem that the resulting linked file had missing dbg entries for AllocaInst values. After some digging I found that llvm::MapValue returns NULL when it encounters an AllocaInst. The attached trivial patch fixes the problem. Is this behaviour intended? Regards, Jacob -- Jacob Zimmermann Oracle Labs, Brisbane, Queensland, Australia jacob.zimmermann at oracle.com -------------- next part -------------- A non-text attachment...

...o it’s probably better to pin some source code here. Below is a piece of code related to my problem, clipped from lib/Transforms/Utils/ValueMapper.cpp. I was wondering what “materialized” means here. Value *Mapper::mapBlockAddress(const BlockAddress &BA) { Function *F = cast<Function>(mapValue(BA.getFunction())); // F may not have materialized its initializer. In that case, create a // dummy basic block for now, and replace it once we've materialized all // the initializers. BasicBlock *BB; if (F->empty()) { DelayedBBs.push_back(DelayedBasicBlock(BA));...

Hello All, I am having a problem with using CloneFunctionInto to clone a function that includes changing the type of a value using the VMap. Specifically, I am using the VMap to change the address space of values that have particular pointer types. The problem seems to be that RemapInstruction successfully changes the operands using the VMap, but the VTy member indicating the type of the

I don't use a function for do the mapping, it may be MapValue(). If it does not work, alias an int identifier for each basic block. Be aware because basic block cannot have the same name (getName) in the same function, but they might have the same name being in different functions. Therefore, take into account the function name as well. Good luck On Thu, J...

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

...quot;Female") > >>> I think it is quirky that `levels<-.factor` allows the duplicated >>> labels, whereas factor does not. > >>> I wrote a function rockchalk::combineLevels to simplify combining >>> levels, but most of the students here like plyr::mapvalues to do it. >>> The use of levels() can be tricky because one must enumerate all >>> values, not just the ones being changed. > >>> But I do understand Martin's point. Its been this way 25 years, it >>> won't change. :). > >> Well.. the above...

...other memory address and call it for example orgCFG and change the CFG by referencing to the orgCFG Thank you for help and patience On 6 June 2013 10:59, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > I don't use a function for do the mapping, it may be MapValue(). If it > does not work, alias an int identifier for each basic block. Be aware > because basic block cannot have the same name (getName) in the same > function, but they might have the same name being in different functions. > Therefore, take into account the function name as well. &g...

I think I understood that, but what I mean is what is the function responsible to do mapping is it MapValue() in ValueMapper.h? Thanks for your help On 6 June 2013 09:54, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > Map every basic block from the CFG to a set of integers. The successors > from the CFG can be used to make the edges in your simplified graph....

...n what they'd like to see? > > Sanjoy's idea makes sense to me, but only if we never need to add > prefix/prologue data after functions are created. Are there any places > where we need/want to add them after the fact? I think so. I see: LinkModules.cpp: Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap, BitcodeReader.cpp: FunctionPrologueWorklist.back().first->setPrologueData(C); InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality); Some of these sites could be refactored so that the Functions are created with the prefix/prologue data they need. I...

...f3a30fd3 in llvm::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so &...

...;s idea makes sense to me, but only if we never need to add >>> prefix/prologue data after functions are created. Are there any places >>> where we need/want to add them after the fact? >> >> I think so. I see: >> >> LinkModules.cpp: Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap, >> BitcodeReader.cpp: FunctionPrologueWorklist.back().first->setPrologueData(C); >> InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality); >> >> Some of these sites could be refactored so that the Functions are created with th...

...::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () >>> from /opt/buildbot/lib/libLLVM-3.6s...

To extwnd on Martin 's explanation : In factor(), levels are the unique input values and labels the unique output values. So the function levels() actually displays the labels. Cheers Joris On 15 Jun 2017 17:15, "Martin Maechler" <maechler at stat.math.ethz.ch> wrote: >>>>> Paul Johnson <pauljohn32 at gmail.com> >>>>> on Wed, 14 Jun

Bruce, Thanks for the explanation. But based on my inspection on the source code, it seems that materialization is related to lazily reading LLVM objects (Module, Function, etc.) into the memory from bitcode files, which is possibly useful during LTO. I’m not sure though. Pei From: <bruce.hoult at gmail.com> on behalf of Bruce Hoult <bruce at hoult.org> Date: Wednesday, June 28,

...quot;, "Male", "Female") > I think it is quirky that `levels<-.factor` allows the duplicated > labels, whereas factor does not. > I wrote a function rockchalk::combineLevels to simplify combining > levels, but most of the students here like plyr::mapvalues to do it. > The use of levels() can be tricky because one must enumerate all > values, not just the ones being changed. > But I do understand Martin's point. Its been this way 25 years, it > won't change. :). Well.. the above is a bit out of context. Your fir...

...dGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > >>>> #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so > >>>> #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > >>>> from /opt/buildbot/lib/libL...

...Impl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>>>>>> #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so >>>>>>> #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () >>>>>>> from /opt/buildbot/l...

...>> prefix/prologue data after functions are created. Are there any > places > > >> where we need/want to add them after the fact? > > > > > > I think so. I see: > > > > > > LinkModules.cpp: > Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap, > > > BitcodeReader.cpp: > FunctionPrologueWorklist.back().first->setPrologueData(C); > > > InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality); > > > > > > Some of these sites could be refac...

...e data after functions are created. Are there any >>> places >>>>>> where we need/want to add them after the fact? >>>>> >>>>> I think so. I see: >>>>> >>>>> LinkModules.cpp: >>> Dst.setPrefixData(MapValue(Src.getPrefixData(), ValueMap, >>>>> BitcodeReader.cpp: >>> FunctionPrologueWorklist.back().first->setPrologueData(C); >>>>> InlineFunction.cpp: Caller->setPersonalityFn(CalledPersonality); >>>>> >>>>> Some of these sites...