search for: x86_64targetinfo

Displaying 12 results from an estimated 12 matches for "x86_64targetinfo".

2016 Mar 30
2
LLD: Possible optimization for TargetInfo
...ions defined in TargetInfo. The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That is a motication to do the following test. As a test, I removed all TargetInfo subclasses except for x86-64, move all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from TargetInfo. The original LLD links itself (with debug info) in 7.499 seconds. The de-virtualized version did the same thing in 7.364 seconds. So it can improve it by 1.8%. I'm just pointing out that there's room there to improve performance, and I&...
2016 Mar 30
4
LLD: Possible optimization for TargetInfo
...member functions are called multiple times for each >> relocation. So the cost of virtual function calls may be non-neglible. That >> is a motication to do the following test. >> >> As a test, I removed all TargetInfo subclasses except for x86-64, move >> all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from >> TargetInfo. >> >> The original LLD links itself (with debug info) in 7.499 seconds. The >> de-virtualized version did the same thing in 7.364 seconds. So it can >> improve it by 1.8%. >> >> I'm just pointing o...
2016 Mar 30
0
LLD: Possible optimization for TargetInfo
...> The TargetInfo member functions are called multiple times for each > relocation. So the cost of virtual function calls may be non-neglible. That > is a motication to do the following test. > > As a test, I removed all TargetInfo subclasses except for x86-64, move all > code from X86_64TargetInfo to TargetInfo, and remove `virtual` from > TargetInfo. > > The original LLD links itself (with debug info) in 7.499 seconds. The > de-virtualized version did the same thing in 7.364 seconds. So it can > improve it by 1.8%. > > I'm just pointing out that there's room the...
2016 Mar 30
0
LLD: Possible optimization for TargetInfo
...etInfo. > > The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That is a motication to do the following test. > > As a test, I removed all TargetInfo subclasses except for x86-64, move all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from TargetInfo. > > The original LLD links itself (with debug info) in 7.499 seconds. The de-virtualized version did the same thing in 7.364 seconds. So it can improve it by 1.8%. > > I'm just pointing out that there's room there to improve...
2016 Mar 31
0
LLD: Possible optimization for TargetInfo
...called multiple times for each >>> relocation. So the cost of virtual function calls may be non-neglible. That >>> is a motication to do the following test. >>> >>> As a test, I removed all TargetInfo subclasses except for x86-64, move >>> all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from >>> TargetInfo. >>> >>> The original LLD links itself (with debug info) in 7.499 seconds. The >>> de-virtualized version did the same thing in 7.364 seconds. So it can >>> improve it by 1.8%. >>> >>...
2016 Mar 31
2
LLD: Possible optimization for TargetInfo
...es for each >>>> relocation. So the cost of virtual function calls may be non-neglible. That >>>> is a motication to do the following test. >>>> >>>> As a test, I removed all TargetInfo subclasses except for x86-64, move >>>> all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from >>>> TargetInfo. >>>> >>>> The original LLD links itself (with debug info) in 7.499 seconds. The >>>> de-virtualized version did the same thing in 7.364 seconds. So it can >>>> improve it by 1.8%. &...
2013 Aug 22
0
[LLVMdev] [RFC PATCH] X32 ABI support for Clang/compiler-rt (Clang patch)
...rWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else { DefineStd(Builder, "i386", Opts); } @@ -3013,20 +3021,31 @@ class X86_64TargetInfo : public X86TargetInfo { public: X86_64TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple) { - LongWidth = LongAlign = PointerWidth = PointerAlign = 64; + const bool IsX32 = (getTriple().getEnvironment() == llvm::Triple::GNUX32); + LongWidth = LongAlign = PointerWidth =...
2016 Mar 31
0
LLD: Possible optimization for TargetInfo
...>>> relocation. So the cost of virtual function calls may be non-neglible. That >>>>> is a motication to do the following test. >>>>> >>>>> As a test, I removed all TargetInfo subclasses except for x86-64, move >>>>> all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from >>>>> TargetInfo. >>>>> >>>>> The original LLD links itself (with debug info) in 7.499 seconds. The >>>>> de-virtualized version did the same thing in 7.364 seconds. So it can >>>>> i...
2018 Jan 04
0
AllocateTarget for ELF objects on Darwin
...9;   1 error generated. The target selection is a little tricky here and I wonder if it's on purpose or not. One solution is to add another line:   TT.setOS(llvm::Triple::UnknownOS); This line removes the OS info from my triple, so that the AllocateTarget() function no longer returns a DarwinX86_64TargetInfo from here: https://github.com/llvm-mirror/clang/blob/71928e1dab585f336f6d0fb337969eda00ccd19c/lib/Basic/Targets.cpp#L491 The problem with DarwinX86_64TargetInfo is, that it's hard-coded for Mach-O. It always sets the same data-layout string in the target description: https://github.com/llvm-mi...
2013 Aug 22
7
[LLVMdev] [RFC PATCH] X32 ABI support for Clang/compiler-rt
Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of
2013 Aug 22
3
[LLVMdev] [NEW PATCH] X32 ABI support for Clang/compiler-rt (Clang patch)
...rWidth == 32 && getLongWidth() == 32 && + getIntWidth() == 32) { + Builder.defineMacro("_ILP32"); + Builder.defineMacro("__ILP32__"); + } } else { DefineStd(Builder, "i386", Opts); } @@ -3013,20 +3021,31 @@ class X86_64TargetInfo : public X86TargetInfo { public: X86_64TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple) { - LongWidth = LongAlign = PointerWidth = PointerAlign = 64; + const bool IsX32 = (getTriple().getEnvironment() == llvm::Triple::GNUX32); + LongWidth = LongAlign = PointerWidth =...
2016 Mar 31
1
LLD: Possible optimization for TargetInfo
...ocation. So the cost of virtual function calls may be non-neglible. That >>>>>> is a motication to do the following test. >>>>>> >>>>>> As a test, I removed all TargetInfo subclasses except for x86-64, >>>>>> move all code from X86_64TargetInfo to TargetInfo, and remove `virtual` >>>>>> from TargetInfo. >>>>>> >>>>>> The original LLD links itself (with debug info) in 7.499 seconds. The >>>>>> de-virtualized version did the same thing in 7.364 seconds. So it can >&g...