search for: valuemapper

Hi all, I was looking at the ValueMapper code this morning and I notice that it doesn't do type mapping for GlobalValues. Is this correct? I ask because I am seeing a case where I'm failing type assertions from ModuleLinker::linkGlobalInits() when an array initializer references an external global. It looks like the external gl...

On 11/01/12 07:50 AM, Michael Muller wrote: > > Hi all, I was looking at the ValueMapper code this morning and I notice that > it doesn't do type mapping for GlobalValues. Is this correct? > > I ask because I am seeing a case where I'm failing type assertions from > ModuleLinker::linkGlobalInits() when an array initializer references an > external global. It l...

> I can reproduce this consistently, but only under an extremely large pile of > code :-) I haven't tried to strip it down to minimal a test case yet, but I > will. One salient difference with the code you've provided is that in my > code, @a is a struct type. However, changing the example to use a minimal > structure doesn't trigger the assertion failure. Is the

=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= wrote: > On 11/01/12 07:50 AM, Michael Muller wrote: > > > > Hi all, I was looking at the ValueMapper code this morning and I notice that > > it doesn't do type mapping for GlobalValues. Is this correct? > > > > I ask because I am seeing a case where I'm failing type assertions from > > ModuleLinker::linkGlobalInits() when an array initializer references an > &g...

...tried. >> >> I'll recreate this situation just to verify that the verifier pass identifies >> the problem, if it doesn't I'll proceed from there but I'm currently assuming >> the problem is entirely ours :-) >> >> If you think the behavior of the ValueMapper is incorrect in this situation, >> I'd prefer to furnish you with a minimal test case - the unreduced form >> involves checking out and building a specific revision of the Crack compiler >> and running one of the tests in "native" (AOT compile) mode. >> >&gt...

...pt when running non-optimized + debug, which I never tried. I'll recreate this situation just to verify that the verifier pass identifies the problem, if it doesn't I'll proceed from there but I'm currently assuming the problem is entirely ours :-) If you think the behavior of the ValueMapper is incorrect in this situation, I'd prefer to furnish you with a minimal test case - the unreduced form involves checking out and building a specific revision of the Crack compiler and running one of the tests in "native" (AOT compile) mode. Thank you for looking into this :-) >...

...+ debug, which I never tried. > > I'll recreate this situation just to verify that the verifier pass identifies > the problem, if it doesn't I'll proceed from there but I'm currently assuming > the problem is entirely ours :-) > > If you think the behavior of the ValueMapper is incorrect in this situation, > I'd prefer to furnish you with a minimal test case - the unreduced form > involves checking out and building a specific revision of the Crack compiler > and running one of the tests in "native" (AOT compile) mode. > > Thank you for loo...

When linking .ll files with llvm-link or llvm-ld, the debug information is corrupted. As my investigation, alloca instruction, used to hold the debug information, nullifies the debug meta information The attachments is the patch for it. Index: lib/Transforms/Utils/ValueMapper.cpp =================================================================== --- lib/Transforms/Utils/ValueMapper.cpp (revision 157974) +++ lib/Transforms/Utils/ValueMapper.cpp (working copy) @@ -85,6 +85,10 @@ // No operands needed remapping. Use an identity mapping. retu...

OK. About the error it’s a long story, so 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 rep...

....html > > Similar to (2) above, this will naturally filter the types that get > linked in to the ones actually used by the code being linked. > > It should also allow the reader to skip records for types that have > already been loaded in the main module. > The ValueMapper or something will need to figure out which types referenced by UUID to map/link in to the dest module. Currently the ValueMapper does not follow UUID references, but these are brought in when the DICompileUnit is mapped since they are all in the retained types list. > > 5. Create a special...

...gt; > Similar to (2) above, this will naturally filter the types that get > linked in to the ones actually used by the code being linked. > > It should also allow the reader to skip records for types that have > already been loaded in the main module. > > The ValueMapper or something will need to figure out which types referenced by UUID to map/link in to the dest module. Currently the ValueMapper does not follow UUID references, but these are brought in when the DICompileUnit is mapped since they are all in the retained types list. > > > 5. Create a s...

...inker::run in lib/Linker/LinkModules.cpp. > > If I move the call to linkNamedMDNodes in ModuleLinker::run to the > last step (just before return false), everything looks good. Not sure > if linkNamedMDNodes must be called earlier. I made that change in response to Chris's change ValueMapper. Metadata mapping is being investigated as part of PR 10553 anyway. So Ill fix this particular regression you have found. Thanks! - Devang > > - xi > > On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <dpatel at apple.com> wrote: >> >> On Aug 4, 2011, at 8:21 AM, Xi Wa...

Hello everyone, If I understand correctly after the Metadata/Value split the Metadata support of RAUW is limited by ValueAsMetadata and MDNodeFwdDecl (i.e. until cycled in MDNode are not resovled). And my question is. Is where any way to replace an MDNode which is referenced by other MDNodes w\o iterating over all MDNodes in LLMVContext to find and replace those references? Unfortunately I

...n different functions. Therefore, take into account the function name as well. Good luck On Thu, Jun 6, 2013 at 10:55 AM, Rasha Omar <rasha.sala7 at gmail.com> wrote: > 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...

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. The > pair (C...

...above, this will naturally filter the types that get > > linked in to the ones actually used by the code being linked. > > > > It should also allow the reader to skip records for types that have > > already been loaded in the main module. > > > > The ValueMapper or something will need to figure out which types > referenced by UUID to map/link in to the dest module. Currently the > ValueMapper does not follow UUID references, but these are brought in when > the DICompileUnit is mapped since they are all in the retained types list. > > > &g...

...above, this will naturally filter the types that get > > linked in to the ones actually used by the code being linked. > > > > It should also allow the reader to skip records for types that have > > already been loaded in the main module. > > > > The ValueMapper or something will need to figure out which types referenced by UUID to map/link in to the dest module. Currently the ValueMapper does not follow UUID references, but these are brought in when the DICompileUnit is mapped since they are all in the retained types list. > > > > > > 5...

Function has its own FunctionType* member as well as a Type* member that it inherits from GlobalValue. The latter can be mutated but not the former, leading to potential strange inconsistencies. While I realize using mutateType is probably going to trigger a bunch of "you're doing it wrong" replies, it seems like mutateType, as a necessary evil, should be virtual and do the right

...lization (i.e. after all function > >>> importing is complete). This actually applies to all module-level > >>> metadata, not just debug, although it is the largest. This can be > >>> added as a separate set of patches. Changes to BitcodeReader, > >>> ValueMapper, ModuleLinker > >> > >> It sounds like this would work well with the "full" LTO implemented > >> by tools/gold-plugin right now. What exactly did you do to improve > >> this? > > > > I don't think it will help with full LTO. The parsing...

...take into account the function name as well. > > Good luck > > > On Thu, Jun 6, 2013 at 10:55 AM, Rasha Omar <rasha.sala7 at gmail.com> wrote: > >> 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 >>> fr...