search for: hasexternallinkag

Displaying 15 results from an estimated 15 matches for "hasexternallinkag".

Did you mean: hasexternallinkage
2005 Feb 20
3
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
...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...
2005 Feb 20
0
[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 address of a function, not with native code: #include <stdio.h> int foo(...
2009 Jan 12
0
[LLVMdev] malloc vs malloc
...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
2007 May 25
0
[LLVMdev] Linking two external linkage GlobalValues
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...
2009 Jan 12
2
[LLVMdev] malloc vs malloc
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,
2010 Oct 28
2
[LLVMdev] global optimizer precision
...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...
2009 Jan 13
2
[LLVMdev] malloc vs malloc
...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...
2013 Jul 08
1
[LLVMdev] Special cased global-to-local-in-main replacement in GlobalOpt
...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...
2013 Apr 23
2
[LLVMdev] Feedback required on proper dllexport/import implementation
...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...
2013 May 07
0
[LLVMdev] Feedback required on proper dllexport/import implementation
...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...
2013 Apr 23
0
[LLVMdev] Feedback required on proper dllexport/import implementation
...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...
2013 May 07
1
[LLVMdev] Feedback required on proper dllexport/import implementation
...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...
2009 Jan 13
0
[LLVMdev] malloc vs malloc
...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...
2009 Jun 16
3
[LLVMdev] Localizing Globals ?
...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
2013 Mar 26
6
[LLVMdev] Feedback required on proper dllexport/import implementation
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