Displaying 20 results from an estimated 500 matches similar to: "[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)"
2016 Jul 22
3
[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
Yes, I have the repro, though I can’t publish it externally. It would be great if you can upstream the patch so I can try it. Thank you for your explanation as well!
-- Taewook
From: <mehdi.amini at apple.com> on behalf of Mehdi Amini <mehdi.amini at apple.com>
Date: Friday, July 22, 2016 at 2:16 PM
To: Taewook Oh <twoh at fb.com>
Cc: via llvm-dev <llvm-dev at
2016 Jul 22
3
[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
It seems that the patch works for me as well, though the linker crashes with another error after that. Thanks!
Mehdi, I couldn’t quite understand what do you mean by you don’t have a repro so you couldn’t upstream the patch. Aren’t .ll files you attached sufficient to submit along with the patch? If there is anything I can help you to upstream it, please let me know.
-- Taewook
On 7/22/16,
2016 Jul 22
2
[ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
On Fri, Jul 22, 2016 at 2:44 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Fri, Jul 22, 2016 at 2:34 PM, Taewook Oh via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Yes, I have the repro, though I can’t publish it externally. It would be
>> great if you can upstream the patch so I can try it. Thank you for your
>> explanation as well!
>
>
2016 Jul 29
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Hello Teresa,
Thank you for your analysis. One thing to note is that the global materializer materializes the value as a function declaration, not a function definition. As I pasted on my first email,
; Materializable
; Function Attrs: nounwind uwtable
define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {}
is materialized to
;
2016 Jul 29
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
It was r274523. I’m not sure it was the same module. By mistake I restarted the build with the previous version without backing backing up the build artifacts :(
Thanks,
Taewook
From: Teresa Johnson <tejohnson at google.com>
Date: Friday, July 29, 2016 at 3:30 PM
To: Taewook Oh <twoh at fb.com>
Cc: via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [ThinLTO]
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
On Thu, Jul 28, 2016 at 5:18 PM, Taewook Oh <twoh at fb.com> wrote:
> Hello Teresa,
>
>
>
> Thank you for your reply. I’m trying to create a small repro but find it
> hard to nail down because originally it is a big build. This happens with
> gold linker.
>
I think I need to see a smaller test case, looking through the code I'm not
sure how we ended up in this
2016 Jul 30
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Yes, if I drop the debug flag then the original problem (assertion failure) comes back.
Thanks,
Taewook
From: Teresa Johnson <tejohnson at google.com>
Date: Friday, July 29, 2016 at 3:52 PM
To: Taewook Oh <twoh at fb.com>
Cc: via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
On Fri, Jul
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
On Fri, Jul 29, 2016 at 2:25 PM, Taewook Oh <twoh at fb.com> wrote:
> Hello Teresa,
>
>
>
> Thank you for your analysis. One thing to note is that the global
> materializer materializes the value as a function declaration, not a
> function definition. As I pasted on my first email,
>
>
>
> ; Materializable
>
> ; Function Attrs: nounwind uwtable
>
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
On Fri, Jul 29, 2016 at 3:40 PM, Taewook Oh <twoh at fb.com> wrote:
> It was r274523. I’m not sure it was the same module. By mistake I
> restarted the build with the previous version without backing backing up
> the build artifacts :(
>
So a couple things were added to gold since then, index-based linkonce/weak
resolution and some more aggressive internalization. I don't
2016 Aug 15
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Hi Taewook,
I had a better fix for this approved (D23015), but when I went to merge
this with the new LTO API I committed for pcc last week I discovered that
his new API already has the same effect. I will update the bug with this
info as well. Can you confirm that with a compiler built after 278338 that
this problem no longer occurs?
Also, any luck on a smaller test case for the -g issue? Now
2016 Aug 15
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
No problem! I want to make sure you aren't blocked on trying ThinLTO.
Thanks,
Teresa
On Mon, Aug 15, 2016 at 2:50 PM, Taewook Oh <twoh at fb.com> wrote:
> Hello Teresa,
>
>
>
> Sorry I was working on another LLVM issue that more urgent for us, so
> didn’t have much time to work on smaller test case. I’ll try the new API
> and see if the issus is gone. Thanks!
>
2016 Jul 30
1
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Ok, good to know.
Any luck on a smaller test case for either of the problems?
I tried building all the C/C++ SPEC cpu2006 benchmarks with -g -flto=thin
at head and didn't get the failure. Let me try to look into how the debug
metadata is normally dropped from the imported decl. In the meantime, could
you find out the answers to the questions I had (see below) about the
linkage type of the
2016 Jul 29
3
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Hello Teresa,
Thank you for your reply. I’m trying to create a small repro but find it hard to nail down because originally it is a big build. This happens with gold linker.
Thanks,
Taewook
From: Teresa Johnson <tejohnson at google.com>
Date: Thursday, July 28, 2016 at 5:08 PM
To: Taewook Oh <twoh at fb.com>
Cc: via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev]
2018 Mar 27
2
IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?
Hi,
On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote:
> > The second approach is to *not* cache modules but re-read them from disk
> > (or memory, but that's irrelevant here). That works without any sort of
> > asserts, but "leaks" memory because everytime a module is re-read from
> > disk it re-creates types (cf
2018 Mar 26
0
IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?
> On Mar 23, 2018, at 16:11, Andres Freund via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> (sorry if the CC's are inappropriate, they seemed relevant based on a
> git log of IRMover.cpp)
>
> I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One
> part of that is doing inlining of operators. For that I'm using bitcode
2018 Mar 23
2
IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?
Hi,
(sorry if the CC's are inappropriate, they seemed relevant based on a
git log of IRMover.cpp)
I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One
part of that is doing inlining of operators. For that I'm using bitcode
pre-generated using clang.
The current code uses a single LLVMContext & Orc to generate the
code. That largely workes well. But inlining
2018 Mar 27
0
IRMover asserts "mapping to a source type" when repeatedly linking - usage or LLVM bug?
> On Mar 26, 2018, at 17:09, Andres Freund <andres at anarazel.de> wrote:
>
> Hi,
>
> On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote:
>>> The second approach is to *not* cache modules but re-read them from disk
>>> (or memory, but that's irrelevant here). That works without any sort of
>>> asserts, but "leaks" memory
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 28
2
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Encountered “assert(GS != DefinedGlobals.end())” failure while running ThinLTO. The assertion statement is in MustPreserveGV lambda function in llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp).
It seems that the assertion fails because it fails to recover the "original name" of the global value. ModuleSummaryIndex::getOriginalNameBeforePromote attempts to get the
2016 Jul 29
0
[ThinLTO] assert(GS != DefinedGlobals.end()) failed in FunctionImport.cpp
Hi Taewook,
On Thu, Jul 28, 2016 at 4:38 PM, Taewook Oh via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Encountered “assert(GS != DefinedGlobals.end())” failure while running
> ThinLTO. The assertion statement is in MustPreserveGV lambda function in
> llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp).
>
>
>
> It seems that the assertion fails