similar to: [LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X

On Feb 20, 2005, at 11:12, Evan Jones wrote: > I can "fix" it by changing JITResolver::getFunctionStub to use > F->isExternal() instead of F->hasExternalLinkage(). However, this then > breaks when calling *real* external functions (native code). I obviously should not post to mailing lists before I've eaten. With my "fix" I get an assertion when taking an

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!

Chris Lattner wrote: > On Mon, 16 Jun 2008, Gary Benson wrote: > > When you genetate code on PowerPC you need to explicitly > > invalidate the instruction cache to force the processor to reread > > it. In LLVM there is code to do this for function stubs on > > Macintosh, but not for other platforms and not for JITted code > > generally. > > Applied, thanks!

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can

Hi, This is probably an easy question, but I could not find the answer to it. I'm working on a LLVM back-end for the EHC compiler (a Haskell compiler). Currently there is a C back-end and I would like to reuse the primitive library functions from this back-end. So I have compiled C sources in a .o file and I would like to call these from my LLVM code. If I declare these primitive functions

There used to be a method in Function called isExternal() that you could call to check if a function is external. That method seems to be removed. What method should now be called to check if a function isExternal? Regards, Ryan -- Ryan M. Lefever [http://www.ews.uiuc.edu/~lefever]

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

> Something like this should work: > > for (Module::iterator F = M->begin(), E = M->end(); F != E; ++F) > if (F->isExternal()) > ... Function* F is external! ... This is not working. For some reason there is a BasicBlock present on undefined functions ! I am compiling the examples from llvm/test/feature, about 28 out of 34 assemble fine. Just cannot seem to get

On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >>> There is no good reason for malloc to be an instruction anymore. >>> I'd >>> be very happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No,

I noticed that folding a cast of a global address to boolean doesn't work like I expected - there is a comment in the code that casts of external symbols should not happen, but I don't understand the rationale for this. // FIXME: When we support 'external weak' references, we have to prevent // this transformation from happening. In the meantime we avoid folding // any cast of

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

How do you determine whether a function is defined externally ? Basically I want a list of external functions but cannot seem to get one. e.g. I want to create the following list for a module EXTERN _printf : NEAR EXTERN _malloc : NEAR EXTERN _an_external_fn : NEAR I have tried all the obvious permutations but cannot seem to get only the extrnally defined symbols. Help, Aaron --------------

Can you upload a reproducer? You can create it using the /linkrepro flag. Peter On Thu, Jun 7, 2018 at 2:50 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > GCC does comdats completely differently from the spec. Since you contacted > me about this off of the mailing list, I started investigating what they > do, and it is completely different. It's

On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > > On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: > >>>> There is no good reason for malloc to be an instruction anymore. >>>> I'd >>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>>

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to

Hi all, I had a look at the interprocedural optimizer. In my opinion the routine 'GlobalOpt::ProcessInternalGlobal' is a little bit to conservative. It removes global variables if the only routine using this variable is main. Typically this condition is valid only for very few global variables. Here is a code snippet containing the test before the transformation: file:

Chris Lattner wrote: > > Second, MO_ExternalSymbol is used for storing name of external > > variable/function, right? Why it's not possible to use MO_GlobalAddress, > > where returned GlobalValue* has isExternal set to true? The > > GlobalValue::getName would return the name of the symbol. > > Using the GlobalValue is certainly the preferred way if you have it.