search for: targetasminfo

Hi all, The current repository (revision 56968.) does not compile on my Linux box (with GCC 3.4.6): X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of `bool llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*) const [with BaseTAI = llvm::TargetAsmInfo]' X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of `bool llvm::X86TargetAsmInfo<BaseTAI>::L...

On Thursday 02 October 2008 12:42, David Greene wrote: > But let's say you _could_ write such a pattern (because I can). The input > DAG looks like this: > > 0x391a220: <multiple use> > 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 > 0x391ac10: <multiple use> > 0x391c8b0: v2f64 = scalar_to_vector

...names would be the way to go. My question is whether getValueName() should do the prepending or should the individual back-end do it? I think that getValueName() should do it so that it's consistent, but then the prefix needs to be passed in (as the mangler doesn't know about the TargetAsmInfo object). What do you think? -bw

...ssert_fail + 239 6 llc 0x0000000000ebfdad 7 llc 0x0000000000ebffa6 8 llc 0x0000000000ec2f7b 9 llc 0x0000000000eb95e0 llvm::DwarfWriter::BeginModule(llvm::Module*, llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*, llvm::TargetAsmInfo const*) + 166 10 llc 0x0000000000b9b513 11 llc 0x0000000001142c73 llvm::FPPassManager::doInitialization(llvm::Module&) + 65 12 llc 0x0000000001142d96 llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) + 58 13 llc 0x00000000...

...generation for that global; > instead we only pass the address information to the linker (home made > linker) through some assembly directives. > What are you trying to do? Are you trying to change the logic of this > part or it is only simple refactoring? My short term goal is to make TargetAsmInfo not depend on libvmcore. This means that no methods in it should take GlobalValue*'s for example. There is a suite of GV classification methods that need to be moved somewhere else, probably in TargetLowering or asmprinter. One method in particular (SectionForGlobal) is virtual and on...

> My short term goal is to make TargetAsmInfo not depend on libvmcore. > This means that no methods in it should take GlobalValue*'s for > example. There is a suite of GV classification methods that need to > be moved somewhere else, probably in TargetLowering or asmprinter. One > method in particular (SectionForGloba...

...t; be the way to go. My question is whether getValueName() should do the > prepending or should the individual back-end do it? I think that > getValueName() should do it so that it's consistent, but then the > prefix needs to be passed in (as the mangler doesn't know about the > TargetAsmInfo object). > > What do you think? > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...and completely the change, so probably someone else should reword that to fit in ReleaseNotes.html: - New argument DisableVerify to llvm::TargetMachine::addPassesToEmitWholeFile (it has a default value, but one must update the declaration of redefinition of this function in derived classes). - TargetAsmInfo changed to MCAsmInfo in back-end writters. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...h the text. It seems to me that your patch changes the ARM backend to optionally handle jump tables in a way that is at least very similar to the default behavior, but you have implemented it without using the existing code. Did you consider implementing it using the LLVM defaults? Using TargetAsmInfo::JumpTableDataSection is one piece of that, but there is more. As a start, you could change ARMJITInfo::hasCustomJumpTables and the "Custom" argument to setOperationAction for ISD::BR_JT in the ARMTargetLowering constructor to be conditional on your new flag. I'm sure there...

...t;, >> + cl::init(".data.jtab")); >> + > > I thought it would be nice to group all the jumptables together. > But as long as it stays configurable, I am fine to change the default > to ".data". There is already a TargetAsmInfo::JumpTableDataSection. Why not just use that? > >> Is this necessary? Why not just put it in the normal data section? >> Also "outline" jumptable seems like a strange term. Can you think of >> something else? > > > Yes, that is a tough one. How about &quot...

On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> wrote: > +cl::opt<std::string> FlagJumpTableSection("jumptable-section", > +                                           cl::init(".data.jtab")); > + I thought it would be nice to group all the jumptables together. But as long as it stays configurable, I am fine to change the default to

...gt; + > >>> > >>> I thought it would be nice to group all the jumptables together. > >>> But as long as it stays configurable, I am fine to change the > >>> default > >>> to ".data". > >> > >> There is already a TargetAsmInfo::JumpTableDataSection. Why not just > >> use that? > > > > Nice find. I will use that and possible change the current setting, > > ".const", if it does not work, > > > >>> > >>>> Is this necessary? Why not just put it in the norm...

....cpp (revision 49716) > +++ lib/Target/PowerPC/PPCBranchSelector.cpp (working copy) > @@ -22,7 +22,6 @@ > #include "PPCPredicates.h" > #include "llvm/CodeGen/MachineFunctionPass.h" > #include "llvm/Target/TargetMachine.h" > -#include "llvm/Target/TargetAsmInfo.h" > #include "llvm/ADT/Statistic.h" > #include "llvm/Support/Compiler.h" > #include "llvm/Support/MathExtras.h" > @@ -54,25 +53,6 @@ > return new PPCBSel(); > } > > -/// getNumBytesForInstruction - Return the number of bytes of code &g...

Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...not a correct substitution. Function::getSection() returns section set on function explicitely, getSectionForFunction() calculated desired section name, where function should be emitted into (for example, unique function name for linkonce stuff). getSectionForFunction() was replaced with universal TargetAsmInfo::SectionForGlobal() hook. See, for example, X86ATTAsmPrinter::emitFunctionHeader() for usage and ELFTargetAsmInfo class for example implementation of this hook. -- WBR, Anton Korobeynikov

...go. My question is whether getValueName() should do the >> prepending or should the individual back-end do it? I think that >> getValueName() should do it so that it's consistent, but then the >> prefix needs to be passed in (as the mangler doesn't know about the >> TargetAsmInfo object). >> >> What do you think? >> >> -bw >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > ___...

On Wednesday 17 June 2009 00:11, Evan Cheng wrote: > Asm printer. Yes, but where? I can't find it. What do I need to search for? -Dave

> On Wednesday 17 June 2009 00:11, Evan Cheng wrote: >> Asm printer. > > Yes, but where? I can't find it. What do I need to > search for? ViewVC is helpful :- http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/ Look at the X86IntelAsmPrinter.cpp file for code outputting the align, if its not there it maybe in the X86AsmPrinter.cpp file, meaning

...number back to its corresponding dwarf register number in function InstPrinter->printRegName? I just want to have it output the same register number as before (the same output the false path would produce). void MCAsmStreamer::EmitRegisterName(int64_t Register) { if (InstPrinter) { const TargetAsmInfo &asmInfo = getContext().getTargetAsmInfo(); unsigned LLVMRegister = asmInfo.getLLVMRegNum(Register, true); InstPrinter->printRegName(OS, LLVMRegister); } else { OS << Register; } } My current implementation of printRegName which I copied from other backends (X86, ARM a...