similar to: [LLVMdev] OCaml binding and basic blocks

Hi, I have a problem - looking for advice. I have a source code file with two functions which are compiled into a .bc file. When the bitcode file is loaded, I can dump the module and see the two functions: ... ; Materializable ; Function Attrs: noinline nounwind uwtable define void @matmul(double*, double*, double*, i32, i32, i32) #0 {} ; Materializable ; Function Attrs: noinline nounwind

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

Hi All, I'm beginning to learn & explore the LLVM API via the C bindings. Am running into some troubles but at the moment cannot tell if this is just my misunderstanding/misuse of the API, or a bug somewhere. I have a bitcode file generated with 'clang --emit-llvm' and I know this is good because I can run the 'test' function inside with lli, no problems. However I run

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 ;

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 >

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

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]

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

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

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]

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

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

Hi, thanks Chris and Gordon for the fantasic infrastructure and ocaml bindings and Erick for the prompt response! I'm looking to use LLVM to write program analyses for C/C++ programs, but to use Ocaml to write the analyses. I did see there were bindings for iterating over: * functions in a module [iter_functions] * basic blocks in a functions [iter_blocks] * instructions in a block

Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > >

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

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! >

> On 2015-May-15, at 13:15, Teresa Johnson <tejohnson at google.com> wrote: > > What isn't clear to me is what all uses the available > externally linkage type currently - do you happen to know? It's used for the `inline` keyword in the C language. If you do a `git grep available_externally -- test/` inside a clang checkout you might find some other uses. $ cat

Hi, I have: ... @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a function\0A\00", align 1 ; Function Attrs: ssp uwtable define i32 @_Z1fv() #2 { entry: %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([21 x i8]* @.str1, i32 0, i32 0)) ret i32 0 } Then I get after trying to erase the function from the module: 511

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

Hi: I am trying to implement interval arithmetic through llvm. I have a problem with the rounding mode with llvm.experimental.constrained.cos I have two pieces of codes: ; Function Attrs: norecurse nounwind readnone ssp uwtable define double @cosine_down(double returned) local_unnamed_addr #0 {   ; call the llvm intrinsic to perform downward cosine