Displaying 13 results from an estimated 13 matches for "foralia".
Did you mean:
foralias
2016 Jul 29
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...sonality i32 (...)* @__gxx_personality_v0 {}
is materialized to
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
BTW, I updated LLVM to the l...
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...opy already linked in from the same source
module:
In IRLinker::linkGlobalValueProto, we should find the DGV created by the
GlobalValueMaterializer for the same SGV (first find it by name, then if
ShouldLink==true, we should find it in ValueMap and return that entry, or
if ShouldLink==false, since ForAlias=true we should return null.
Then when linkGlobalValueProto returns, in IRLinker::materialize there is
specific handling for this case:
// When linking a global for an alias, it will always be linked. However
we
// need to check if it was not already scheduled to satify a reference
from a
//...
2016 Jul 29
3
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...le
; Function Attrs: nounwind uwtable
define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {}
(I renamed the function and comdat)
is materialized with GlobalValueMaterializer, (so the IRLinker::materialize function is called with ForAlias == false), and the materialized value is
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Then, later, the same value is materialized again with LocalValueMaterializer (so ForAlias == true for IRLinker::materialize), and the materialized valu...
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...rialized to
>
>
>
> ; Function Attrs: nounwind uwtable
>
> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>
>
>
> Inside IRLinker::linkGlobalValueProto, the materialized value is returned
> from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is
> true and ShouldLink is false, DGV becomes nullptr later, and NewGV is
> created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore,
> returned value from linkGlobalValueProto is different from the value
> obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
>
Ah,...
2016 Jul 29
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...y i32 (...)* @__gxx_personality_v0 {}
is materialized to
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
Ah, sorry, somehow I complet...
2016 Jul 28
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...lizable
; Function Attrs: nounwind uwtable
define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {}
(I renamed the function and comdat)
is materialized with GlobalValueMaterializer, (so the IRLinker::materialize function is called with ForAlias == false), and the materialized value is
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Then, later, the same value is materialized again with LocalValueMaterializer (so ForAlias == true for IRLinker::materialize), and the materialized value is...
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...rialized to
>
>
>
> ; Function Attrs: nounwind uwtable
>
> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>
>
>
> Inside IRLinker::linkGlobalValueProto, the materialized value is returned
> from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is
> true and ShouldLink is false, DGV becomes nullptr later, and NewGV is
> created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore,
> returned value from linkGlobalValueProto is different from the value
> obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
>
>...
2016 Jul 30
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...y i32 (...)* @__gxx_personality_v0 {}
is materialized to
; Function Attrs: nounwind uwtable
declare void @foo(%"type1"*) unnamed_addr #2 align 2
Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
Ah, sorry, somehow I complet...
2016 Jul 30
1
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...rialized to
>
>
>
> ; Function Attrs: nounwind uwtable
>
> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>
>
>
> Inside IRLinker::linkGlobalValueProto, the materialized value is returned
> from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is
> true and ShouldLink is false, DGV becomes nullptr later, and NewGV is
> created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore,
> returned value from linkGlobalValueProto is different from the value
> obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
>
>...
2016 Aug 15
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...t;>>
>>> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>>>
>>>
>>>
>>> Inside IRLinker::linkGlobalValueProto, the materialized value is
>>> returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as
>>> ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and
>>> NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call.
>>> Therefore, returned value from linkGlobalValueProto is different from the
>>> value obtained by ValueMap.lookup(SGV) in IRLinker::mat...
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...gt; define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2
> personality i32 (...)* @__gxx_personality_v0 {}
>
> (I renamed the function and comdat)
>
>
>
> is materialized with GlobalValueMaterializer, (so the
> IRLinker::materialize function is called with ForAlias == false), and the
> materialized value is
>
>
>
> ; Function Attrs: nounwind uwtable
>
> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>
>
>
> Then, later, the same value is materialized again with
> LocalValueMaterializer (so ForAlias == true...
2016 Aug 15
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
...rialized to
>
>
>
> ; Function Attrs: nounwind uwtable
>
> declare void @foo(%"type1"*) unnamed_addr #2 align 2
>
>
>
> Inside IRLinker::linkGlobalValueProto, the materialized value is returned
> from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is
> true and ShouldLink is false, DGV becomes nullptr later, and NewGV is
> created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore,
> returned value from linkGlobalValueProto is different from the value
> obtained by ValueMap.lookup(SGV) in IRLinker::materialize.
>
>...
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