search for: hasexternallinkag

...uot;DoesntNeedStub" is set, so JITEmitter::getPointerToGlobal calls AddCallbackAtLocation instead of getFunctionStub. In JITResolver::getFunctionStub, the function that is being resolved is "add1", and it is marked as "Linkage = ExternalLinkage". The code uses F->hasExternalLinkage() to decide if the function is external or not. This returns true, so instead of emitting a stub, it calls TheJIT->getPointerToFunction. In TheJIT->getPointerToFunction, it uses F->isExternal() to decide if it should run the JIT or not. This returns false, so it decides to run th...

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 address of a function, not with native code: #include <stdio.h> int foo(...

...n > MallocInst > would also have a reason to be kept. isa<FreeInst>(X) can be replaced with: bool isFree(Instruction *X) { if (CallInst *CI = dyn_cast<CallInst>(X)) if (Function *F = CI->getCalledFunction()) if (F->isName("free") && F->hasExternalLinkage()) return true; return false; } There is no need to have an actual IR object for it. posix_memalign, calloc, valloc and others are all great reasons why we shouldn't have a MallocInst either. -Chris

Hi, I've been able to link ioquake, but not without a small modification to lib/Linker/LinkModules.cpp:427 where I had to add: } else if (Dest->hasExternalLinkage() && Src->hasExternalLinkage()){ LinkFromSrc = true;//overwrite old value LT = Src->getLinkage();//use src linkage The reason is that two files both had a global function pointer variable (due to #include's): void ( *alEnable)( ALenum capability ); which got tr...

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,

...tipleAccessingFunctions && GS.AccessingFunction && !GS.HasNonInstructionUser && GV->getType()->getElementType()->isSingleValueType() && GS.AccessingFunction->getName() == "main" && GS.AccessingFunction->hasExternalLinkage() && GV->getType()->getAddressSpace() == 0) { The comment above the test states the reason for the check for main which is: main is not recursive. My proposal is to introduce a routine to check if a function is recursiv (returning false, only if its not recursiv for sure). T...

...have a reason to be kept. > > isa<FreeInst>(X) can be replaced with: > > bool isFree(Instruction *X) { > if (CallInst *CI = dyn_cast<CallInst>(X)) > if (Function *F = CI->getCalledFunction()) > if (F->isName("free") && F->hasExternalLinkage()) Surely you mean "llvm.free" or something, right? I don't think we want to start assigning meaning to otherwise arbitrary function names. Nick > return true; > return false; > } > > There is no need to have an actual IR object for it. posix_memalign...

...S.HasMultipleAccessingFunctions && GS.AccessingFunction && !GS.HasNonInstructionUser && GV->getType()->getElementType()->isSingleValueType() && GS.AccessingFunction->getName() == "main" && GS.AccessingFunction->hasExternalLinkage() && GV->getType()->getAddressSpace() == 0) { >From today's discussion on IRC, there appear to be two problems with this approach: 1) The hard-coding of "main" to mean "entry point to the code" that only dynamically runs once. 2) Assuming that &quot...

...approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may be existing compiler codes that rely on this semantics. If I used external_linkage > + some attribute, then any place in existing codes that uses hasExternalLInkage() will > have to be modified to check both the linkage type as well as the attribute list, which > seems a bit fragile to maintain; somebody somewhere will forget to check the attributes > when writing their new optimization or garbage collection passes. What problems do you expect with...

...ear to involve adding flags or attribute to an existing linkage type, so any existing compiler codes that deal with that particular linkage type will potentially have different behavior. For example, if you replace the DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then codes that check hasExternalLinkage() will affect DLLExportLinkage symbols as well, which may or may not be the right thing. For example, LTO::addDefinedSymbol() currently does not handle dllimport/dllexport symbols, but if you change the semantics of ExternalLinkage to include dllimport/dllexport, then you could potentially have ch...

...some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on this semantics. If I used external_linkage + some attribute, then any place in existing codes that uses hasExternalLInkage() will have to be modified to check both the linkage type as well as the attribute list, which seems a bit fragile to maintain; somebody somewhere will forget to check the attributes when writing their new optimization or garbage collection passes. I think dllimport inline functions are more clos...

...will > potentially have different behavior. Right. But normally LLVM API does not provide backward compatibility. The point is to make good code / API, not to fix the broken one with hinges and supports. > DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then > codes that check hasExternalLinkage() will affect DLLExportLinkage > symbols as well, which may or may not be the right thing. In this case everything should work fine. If the behavior will be changed, then we'll find some subtle bug hiding there for ages. normal dllexport'ed functions are essentially external functions w...

...wycky wrote: >> isa<FreeInst>(X) can be replaced with: >> >> bool isFree(Instruction *X) { >> if (CallInst *CI = dyn_cast<CallInst>(X)) >> if (Function *F = CI->getCalledFunction()) >> if (F->isName("free") && F->hasExternalLinkage()) > > Surely you mean "llvm.free" or something, right? I don't think we want > to start assigning meaning to otherwise arbitrary function names. No, I mean "free". Dan Gohman and I discussed this today. A short version in no particular order is: 1) in practi...

...tipleAccessingFunctions && GS.AccessingFunction && !GS.HasNonInstructionUser && GV->getType()->getElementType()->isSingleValueType() && GS.AccessingFunction->getName() == "main" && GS.AccessingFunction->hasExternalLinkage()) { DOUT << "LOCALIZING GLOBAL: " << *GV; What if my global variable was into a different address space than stack? How do I deny this optimization in that case? Can I find address space for stack from AllocaInst and then compare the address spaces for two? - Sanjiv

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but