search for: targetinfo

I was wandering how much is the overhead of virtual function calls of TargetInfo member functions. TargetInfo handles platform-specific details, and we have target-specific subclasses of that class. The subclasses override functions defined in TargetInfo. The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be...

Michael, I'm looking at flushing out the mach-o driver and targetinfo. Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once lld takes over, the term ld64 won't mean anything. I've worked thr...

...current scheme, since the target is fixed, all the > indirect call sites should be monomorphic and so there shouldn't be much > branch-prediction cost (certainly nothing that would cause 1.8% performance > delta for the entire link). > Agreed. We could template functions that call TargetInfo's member functions for each target to eliminate the virtual function calls. > Notice that 1.8% is smaller than the performance variation from r263227 > which is a very innocuous-looking change but caused ~2-3% slowdown for > ScyllaDB (see the thread "LLD performance w.r.t. local...

...ven in the current scheme, since the target is fixed, all the indirect call sites should be monomorphic and so there shouldn't be much branch-prediction cost (certainly nothing that would cause 1.8% performance delta for the entire link). > > Agreed. We could template functions that call TargetInfo's member functions for each target to eliminate the virtual function calls. Are you measuring with a build of LLD with LTO+PGO (+ICP+WholeDevirtualization...)? We have compiler technologies to address these problems, I think we'd better leave it to them when they can handle it. -- Mehdi...

...wdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)"). -- Sean Silva On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wandering how much is the overhead of virtual function calls of > TargetInfo member functions. TargetInfo handles platform-specific details, > and we have target-specific subclasses of that class. The subclasses > override functions defined in TargetInfo. > > The TargetInfo member functions are called multiple times for each > relocation. So the cost of virtu...

...Sands wrote: > Hi Jack, > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > build fails as... > > what does the command > ./TargetInfo -p > return (the TargetInfo program is created during the dragonegg build). > Some of your errors are consistent with this program failing to run. > Duncan, Yes, the result from "./TargetInfo -p" is incorrect under darwin10... x86 In FSF config.guess, we had to add......

...e target is fixed, all the >> indirect call sites should be monomorphic and so there shouldn't be much >> branch-prediction cost (certainly nothing that would cause 1.8% performance >> delta for the entire link). >> > > Agreed. We could template functions that call TargetInfo's member > functions for each target to eliminate the virtual function calls. > >From what has been presented I would not conclude that virtual calls are actually the problem (or a problem at all). A root-cause analysis is necessary. As r263227 shows, the relocation application loop i...

...he >>> indirect call sites should be monomorphic and so there shouldn't be much >>> branch-prediction cost (certainly nothing that would cause 1.8% performance >>> delta for the entire link). >>> >> >> Agreed. We could template functions that call TargetInfo's member >> functions for each target to eliminate the virtual function calls. >> > > From what has been presented I would not conclude that virtual calls are > actually the problem (or a problem at all). A root-cause analysis is > necessary. As r263227 shows, the reloca...

...; > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > > build fails as... > > > > what does the command > > ./TargetInfo -p > > return (the TargetInfo program is created during the dragonegg build). > > Some of your errors are consistent with this program failing to run. > > > > Duncan, > Yes, the result from "./TargetInfo -p" is incorrect under darwin10... > > x86 &gt...

...rect call sites should be monomorphic and so there shouldn't be much >>>> branch-prediction cost (certainly nothing that would cause 1.8% performance >>>> delta for the entire link). >>>> >>> >>> Agreed. We could template functions that call TargetInfo's member >>> functions for each target to eliminate the virtual function calls. >>> >> >> From what has been presented I would not conclude that virtual calls are >> actually the problem (or a problem at all). A root-cause analysis is >> necessary. As r...

> Are you looking in Clang's source, and that from the same 7.0 version? Yes, I am, and it’s the same version (7.0.1). “LargeArrayMinWidth” is only on the following files: TargetInfo.cpp TargetInfo.h So I still think there’s something else that makes the difference on the x86 target. Anyway, I will now investigate other targets as my temporary frontend. It is right that other targets do not create such big alignments. Thanks for your help. John Tel: 620 28 45 13 > On...

On Wed, Jan 23, 2013 at 6:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > I'm looking at flushing out the mach-o driver and targetinfo. > > Can we rename the "ld64" flavor to "darwin". The command line tool on MacOSX is called "ld" - just like on unix. The name ld64 is the current source repository name for the linker. Once lld takes over, the term ld64 won't mean anything. Sounds fine....

...ld be monomorphic and so there shouldn't be much >>>>> branch-prediction cost (certainly nothing that would cause 1.8% performance >>>>> delta for the entire link). >>>>> >>>> >>>> Agreed. We could template functions that call TargetInfo's member >>>> functions for each target to eliminate the virtual function calls. >>>> >>> >>> From what has been presented I would not conclude that virtual calls are >>> actually the problem (or a problem at all). A root-cause analysis is >...

...t RISC ISA, which does not have unaligned memory access instructions (e.g., LWL, LWR, SWL, and SWR in MIPS). Since char and short variables are not 32-bit alignment, these variables cannot be correctly accessed. Therefore, alignment member functions, especially getCharAlign() and getShortAlign() of TargetInfo class in clang/include/clang/Basic/TargetInfo.h, should be virtual, in order to achieve an ISA-specific alignment in an ISA-specific subclass of TargetInfo class. In my subclass, these return values are 32. Sincerely, Hiroyuki Chishiro -- Hiroyuki Chishiro <chishiro at pf.is.s.u-tokyo.ac.jp&g...

Hi Jack, > Also note that under darwin10, on a EMT64-capable hardware, I get... > > ./TargetInfo -t > x86_64-apple-darwin10.5.0 > > ./TargetInfo -a > x86_64 > > ./TargetInfo -p > x86 > > So it appears that TargetInfo needs to be called with -a and not -p on darwin10. no, it is correct. The -p option is used to determine which subdirectory of the dragonegg source sh...

...s smaller than 16 bytes are specified to be aligned to 1 byte, but bigger ones are aligned to 16 bytes. On the LLVM backend, this creates bigger than necessary frame index offsets, which are undesirable for my architecture. As a side note, my target machine is 16 bits, so I have already modified ‘TargetInfo.ccp' with 16 bit ints and pointers, which works like a charm PointerWidth = PointerAlign = 16; IntWidth = IntAlign = 16; The Question is: - How do I make CLang to emit code with smaller array alignment, say 2 or 4 byte aligned arrays? - Otherwise, is there a way to override that alignmen...

...e > unaligned memory access instructions (e.g., LWL, LWR, SWL, and SWR in > MIPS). > Since char and short variables are not 32-bit alignment, these > variables cannot be correctly accessed. > Therefore, alignment member functions, especially getCharAlign() and > getShortAlign() of TargetInfo class in > clang/include/clang/Basic/TargetInfo.h, should be virtual, in order to > achieve an ISA-specific alignment in an ISA-specific subclass of > TargetInfo class. > In my subclass, these return values are 32. Even if you fix TargetInfo, the assumption that getCharSize() == getCh...

Duncan, Many thanks for your comments. The core issue we're running into is this: $ GCC=/usr/bin/gcc LLVM_CONFIG=/usr/bin/llvm-config make Compiling utils/TargetInfo.cpp Linking TargetInfo ld: fatal: library -lLLVMSupport: not found ld: fatal: file processing errors. No output written to TargetInfo collect2: error: ld returned 1 exit statusAll other gyrations are attempts to shoehorn LLVMSupport into the compile. I've been sourcing the Makefile and README f...

...er errors... GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config VERBOSE=1 ENABLE_LLVM_PLUGINS=1 make CPPFLAGS="-g -DENABLE_LTO -I/sw/include" /sw/lib/gcc4.7/bin/gcc-4 --version > /dev/null /sw/opt/llvm-3.2/bin/llvm-config --version > /dev/null Compiling utils/TargetInfo.cpp /sw/lib/gcc4.7/bin/g++-4 -c -DTARGET_TRIPLE=\"x86_64-apple-darwin12.2.0\" \ -g -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.2/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -Wcovered-switch-default -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_...

...current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSectionBase::writeTo \_ InputSection::writeTo \_ InputSection::relocate \_ TargetInfo::relocateOne The problem is only at TargetInfo::relocate the target (aarch64) will see that the relocation is a R_AARCH64_ABS64 one and thus will need to create a dynamic R_AARCH64_RELATIVE relocation. Also from comments at ELF/Writer.cpp:243 I noted that scanRelocs is done early as a design ch...