similar to: RPC on LLVM IR: any example programs for this?

Hi Lang, Thanks for your reply! It seems that the code of ORC has been changed a lot these months. Actually what I wanted to see then was quite simple, Let's say we have two modules M1.bc and M2.bc, and in M1 we want to call function foo(defined in M2.bc)with the function type int foo(float, char*){...} what basic steps do I need to do to make M1.bc call foo remotely? BTW, does the

Hi Rafael, > What prevents you from using a diag handler in the jit server that > sends errors/warnings over the RPCChannel? What would you do with errors that can't reasonable be serialized when they reach the diagnostic handler? And what would you do with the serialized bytes on the client end? - Lang. Sent from my iPhone On Feb 10, 2016, at 10:31 AM, Rafael Espíndola

Hi, I just tagged 3.9.1-rc2, so testing can begin. There was a bug found in -rc1 before I could send out a release announcement, so I decided to merge the fix and tag -rc2 to save some testing cycles. We can always use more testers, so if you are interested in helping, let me know. Thanks, Tom

James, Thanks for the detailed response. Please see my thoughts inline. On Thu, Sep 17, 2020 at 12:33 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi Rahman, > > Traditionally, the ability to read sections is a feature added to > llvm-readobj/llvm-readelf. For some sections, it delegates to methods in > places like the Object library and BinaryFormat, but

Hi All, Now that this thread has accumulated some feedback, I thought I'd try to summarize my thoughts on error handling in LLVM, and why I think this proposal is worth adopting: (1) Failure to check an error *is* a programmatic error, and our error system should reflect this. This makes it easy to spot mistakes in our error handling and correct them. (2) Error returns should describe all

Hello, Disclaimer: I have no plan to break 3.x bitcode compatibility in any way. I’m experimenting with ideas to improve the current bitcode serialization and deserialization in general. I’m interested in improving the speed and the flexibility of the reader/writer, as well as making the code easier to deal with. My current griefs against our bitcode format are mainly the lack of built-in

On Mon, Jul 17, 2017 at 5:18 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > 2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org>: > >> >> >> On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hey @chandlerc and @dblaikie, >>>

On Dec 8, 2007, at 1:13 AM, Reid Spencer wrote: > Hi, > > I'm trying to separate the Support, System, ADT and Config header > files > into the support module, per previous plans. However, APFloat.h is not > self-contained: > > APFloat.h:105:43: error: llvm/Bitcode/SerializationFwd.h: No such file > or directory > APFloat.h:106:37: error:

Dear community, we are currently facing a problem related to the new type system in llvm 3.0. Our setting is the following: We have two or more modules, all in the same LLVMContext. They are sharing some types, meaning that for example functions in different modules are referencing the same (meaning pointer identical) type. Now we write the different modules to the disk, and read them back

On Wed, Jul 19, 2017 at 8:43 AM Teresa Johnson <tejohnson at google.com> wrote: > On Wed, Jul 19, 2017 at 8:31 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, Jul 17, 2017 at 5:18 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >> >>> 2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev < >>> llvm-dev at

> On Sep 28, 2016, at 2:03 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > > On Tue, Sep 27, 2016 at 12:56 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hello, > > Disclaimer: I have no plan to break 3.x bitcode compatibility in any way. > > I’m experimenting with ideas to

Hi Rafael, > But they are always created, even if it as error the caller wants to > ignore. For example, you will always create a "file foo.o in bar.a is > not a bitcode" message (or copy sufficient information for that to be > created). With a dignostic handler no copying is needed, since the > call happens in the context where the error is found. It is easy to > see

While checking for serialization/deserialization without using pointee types, I've come across a few test cases that crash at head, without my debugging assertions for accessing pointee types. One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll Its retainedTypes metadata points to a metadata array of a single null element. This crashes the dyn_cast (because it's not a

On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey @chandlerc and @dblaikie, > > Any updates on this in relation to "[PATCH] D34080: [ThinLTO] Add > dump-summary command to llvm-lto2 tool"? > Sorry you've kind of got stuck in the middle of this - but I'm still hoping to hear/understand the pushback on

I'm sorry that I should remove the comment. In fact my question is about the "float (i32)* (float (i32)*)*", why we use this kind of return type instead of just "float (i32)*". Thanks a lot. Hao On Mon, Apr 12, 2010 at 5:42 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Hao Shen, > >> %4 = call float (i32)* (float (i32)*)* @get_ptr(float (i32)* @a1)

Hello, Are there any recipe to handle serialization / deserialization of external pointers. I'm thinking about something similar in spirit to the way we handle finalization of external pointers. Currently, if we create an external pointer, save the session, quit R, then load the session, we get a null pointer. One way I'm thinking of is to have an environment in the

John, thanks for your helpful advice. My ultimate goal is to construct a full instruction-level program dependence graph for a given IR file. The hard point is how to establish the correct data dependence edges when some function arguments are multi-level pointers. To solve this problem I hope to check the point-to level for each pointer variable. I think the data dependence through pointers can

Hello Charles, Thank you so much for your help. Just run upsc and it is possible that input.transfer.low is the one because we used power regulator to bring down the power around 84v and then the ups sent the power loss message to PC. Do you think some others may take effect for the low voltage? Just have the upsc result attached. Then I retried input.transfer.low, default.input.transfer.low,

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > > > Not sure I follow? Generally LTO inputs are going to be "user provided" > (in the sense that they're not produced immediately prior by the same > process - or you'd have just produced a single Module in the first place, I > would imagine) so changing the default

Dear list, Let's say we have a data frame as follows, >expand.grid(a=1:5,b=c(1,5,10,20),DV=c(0.1,0.2,0.3))->df1 >df1$DV<-rgamma(60,shape=10) columns a and b are two levels. DV is the column with values we are interested in. Then another data frame df2 with values as follows data.frame(a=c(2,2,3,4,5),b=c(5,10,1,5,20))->df2 Now I want to a subset of df1 that match df2 at the