Displaying 4 results from an estimated 4 matches for "sharedmd".
Did you mean:
sharedmds
2016 Jul 26
4
'invalid subroutine type ref' when linking custom metadata
With 3.9, llvm-link tells me 'invalid subroutine type ref' when
linking the two code pieces below, and I don't quite understand why.
It looks like it merges the debug information with the custom
metadata. I've filed a ticket already [1] but as I'm not sure if this
is indeed a bug or if I'm misunderstanding something, I thought I'd
ask here.
Any ideas? Thanks,
Robin
2016 Jul 22
2
[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
...asses ((tools/gold/gold-plugin.cpp) --> FunctionImporter::importFunctions.
As these two IRMovers share the same destination module, when the second IRMover tries to map the metadata already mapped by the first IRMover, it eventually results the assertion failure. It seems that IRMover maintains SharedMDs to keep the metadata mapping record across the multiple calls of its move function, but that doesn’t help between two separate IRMovers.
What would be the right fix for this? Please let me know if I misunderstand something.
Thanks,
Taewook
-------------- next part --------------
An HTML attach...
2016 Jul 27
1
'invalid subroutine type ref' when linking custom metadata
...n in other ways.
But I can see how it would make sense here. Maybe, when an MDNode operand that is a ConstantAsMetadata gets RAUW'ed to "null" and/or deleted, we should drop uniquing from the MDNode. This is a more targeted version of the historical behaviour. It would prevent the SharedMDs entry from being reused in this case.
>
> Thanks,
>
> —
> Mehdi
>
>
>>
>>> cat a.ll
>> define void @a() {
>> ret void
>> }
>>
>> !bar = !{!3}
>>
>> !3 = !{void ()* @a}
>>
>>> cat b.ll...
2016 Jul 22
3
[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
...Passes ((tools/gold/gold-plugin.cpp)--> FunctionImporter::importFunctions.
As these two IRMovers share the same destination module, when the second IRMover tries to map the metadata already mapped by the first IRMover, it eventually results the assertion failure. It seems that IRMover maintains SharedMDs to keep the metadata mapping record across the multiple calls of its move function, but that doesn’t help between two separate IRMovers.
What would be the right fix for this? Please let me know if I misunderstand something.
Thanks,
Taewook
_______________________________________________
LLVM D...