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...