search for: visibility_hidden

...erAllocator.h" #include "llvm/Target/TargetInstrInfo.h" #include "llvm/Target/TargetMachine.h" #include "llvm/Support/CommandLine.h" @@ -79,7 +80,8 @@ /// - break ties when picking regs? (probably not worth it in a /// JIT context) /// - class VISIBILITY_HIDDEN RABigBlock : public MachineFunctionPass { + class VISIBILITY_HIDDEN RABigBlock : public MachineFunctionPass, + public RegisterAllocator { public: static char ID; RABigBlock() : MachineFunctionPass((intptr_t)&ID) {} Index: llvm/lib/CodeGen/RegA...

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

...port/MemoryObject.h, you changed all "uintptr_t" to "uint64_t". Is there a good reason for this? If not, please change them back. 4. If you have a class that's completely contained within a .cpp file, go ahead and define it in an anonymous namespace and mark it "VISIBILITY_HIDDEN". Like this: namespace { class VISIBILITY_HIDDEN StringMemoryObject : public MemoryObject { ... 5. In "readBytes" in StringMemoryObject, you're returning a "-1", but the method's return type is "uint64_t". Do you *really* want to return 0xfffffffffff...

Dear mailing list: the attached diff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the

...t allows tablegen to compile: Index: TableGen/ClangDiagnosticsEmitter.cpp =================================================================== --- TableGen/ClangDiagnosticsEmitter.cpp (revision 68202) +++ TableGen/ClangDiagnosticsEmitter.cpp (working copy) @@ -135,7 +135,7 @@ namespace { struct VISIBILITY_HIDDEN CompareOptName { - bool operator()(const Record* A, const Record* B) { + bool operator()(const Record* A, const Record* B) const { return getOptName(A) < getOptName(B); } };

...source lines after applying this patch. I can't view variables > because I haven't implemented Dwarf type data, yet. Cool! I'm glad to see progress on the sparc backend: +++ lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp (working copy) @@ -44,6 +44,8 @@ namespace { class VISIBILITY_HIDDEN SparcAsmPrinter : public AsmPrinter { + DwarfWriter *DW; + This shouldn't be needed, the AsmPrinter base class now has this. This allows you to remove SparcAsmPrinter::doInitialization. Otherwise, looks great, please apply. -Chris

Please review the enclosed patch for Sparc debug info. I have been able to view source files, set breakpoints, and single step source lines after applying this patch. I can't view variables because I haven't implemented Dwarf type data, yet. -Rich -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sparcdebug.patch URL:

...the source of the bytes is a 64-bit address space), then I don't want to be limited by the local process's notion of uintptr_t. > 4. If you have a class that's completely contained within a .cpp > file, go ahead and define it in an anonymous namespace and mark it > "VISIBILITY_HIDDEN". Like this: > > namespace { > class VISIBILITY_HIDDEN StringMemoryObject : public MemoryObject { > ... I used VISIBILITY_HIDDEN for both StringMemoryObject and X86DisassemblerEmitter::X86DEBackend. I wrapped StringMemoryObject in an anonymous namespace. I didn't wrap X86DEB...

Chris Lattner wrote: > Cool! I'm glad to see progress on the sparc backend: > > +++ lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp (working copy) > @@ -44,6 +44,8 @@ > > namespace { > class VISIBILITY_HIDDEN SparcAsmPrinter : public AsmPrinter { > + DwarfWriter *DW; > + > > This shouldn't be needed, the AsmPrinter base class now has this. This > allows you to remove SparcAsmPrinter::doInitialization. > > Otherwise, looks great, please apply. Thanks Chris, I'm in th...

I'm trying to create the Machine LICM pass and I have this defined: class VISIBILITY_HIDDEN MachineLICM : public MachineFunctionPass { ... public: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<MachineLoopInfo>(); AU.addRequired<MachineDominatorTree>(); } ... }; But when I go to use it:...

Hi!! This is my first time with llvm. I'm still learning and really need help. I wrote only one Function Pass, which uses another Function Pass (blockNrs), and registered this: RegisterPass<FunctionAnalysis> X("gasched", "Genom Scheduling Pass"); When I compile my sourcecode, everything was okay. But when I tried to test it, i got this error Message: nicole at

Hi Devang, > Did you use static ID ? For example ... > > class VISIBILITY_HIDDEN GVN : public FunctionPass { > bool runOnFunction(Function &F); > public: > static char ID; // Pass identification, replacement for typeid > GVN() : FunctionPass((intptr_t)&ID) { } > ... > Yes, I did. And actually everything was doing fine until I added g...

Hi Evgenii, I have one question about this (planned) change: what if a function is not inlined? The linker will not ODR merge them with this change, which isn’t great. What makes “internal” linkage more desirable than "linkonce_odr + visibility hidden"? — Mehdi > On Jul 12, 2016, at 6:16 PM, Evgenii Stepanov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi,

...(revision 51935) +++ gcc/llvm-backend.cpp (working copy) @@ -51,6 +51,7 @@ #include "llvm/Support/Streams.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/MemoryBuffer.h" +#include "llvm/System/Program.h" #include <cassert> #undef VISIBILITY_HIDDEN extern "C" { @@ -272,6 +273,10 @@ PerModulePasses = new PassManager(); PerModulePasses->add(new TargetData(*TheTarget->getTargetData())); + // If writing to stdout, set binary mode. + if (asm_out_file == stdout) + sys::Program::ChangeStdoutToBinary(); + // Emit an L...

...u only provide a declaration. Which is why I am trying to supply this additional information in a custom alias analysis pass, but it doesn't seem to work. (The AAEvalPass stats are precisely for this custom pass.) Could you take a look at the code, please? Am I missing something here? class VISIBILITY_HIDDEN MySretAliasAnalysis : public FunctionPass, public AliasAnalysis { std::map<std::string, bool> _srets; public: static char ID; MySretAliasAnalysis() : FunctionPass(&ID) { _srets["sample$int$float2"] = true; _srets["sample$int$float3"] = true; } void getAnal...

...sign a framework where everything is reusable. But there are two things you can look at. The first is that g++ doesn't (didn't?) properly support anonymous namespaces. Things in anonymous namespaces don't need to have symbols created for them. Second, LLVM classes are littered with VISIBILITY_HIDDEN. Everything else is public. > OTOH, I'll like to distribute LLVM as a separate set of files and not to > force my users to update them every time my compiler changes. > > One solution is to add annotations only to those classes that shall be > visible by the LLVM user and crea...

Hi Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value

...d to using CallSite). 3. llvm.mem{cpy,move,set}.* intrinsics take 1 additional param. I used UpgradeIntrinsic* to make them work, since Intrinsic::getDeclaration was changed in an incompatible way too. Are there any other intrinsics that changed? 4. SetCurrentDebugLocation takes a DebugLoc now 5. VISIBILITY_HIDDEN is gone 6. SMDiagnostic takes different parameters 7. APIs renamed: llvm_report_error -> report_fatal_error llvm_install_error_handler -> install_fatal_error_handler llvm::DwarfExceptionHandling -> llvm::JITExceptionHandling 8. disable calls to memory_barrier. this is not correct for SMP b...

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive

...ningTree.cpp 1970-01-01 01:00:00.000000000 +0100 > +++ llvm-c7/lib/Analysis/MaximumSpanningTree.cpp 2009-06-26 16:47:01.000000000 +0200 ... > +#define WOOD_REP(M,V1,V2) \ Please use "forest" instead of "wood". > + // compare two weighted edges > + struct VISIBILITY_HIDDEN EdgeWeightCompare { > + bool operator()(const ProfileInfo::EdgeWeight X, > + const ProfileInfo::EdgeWeight Y) const { > + if ( X.second > Y.second ) return true; > + if ( X.second < Y.second ) return false; > + if ( X.first.first != 0 &&...