David Woodhouse
2014-Jan-06 15:18 UTC
[LLVMdev] Why do X86_32TargetMachine and X86_64TargetMachine classes exist?
These two subclasses of X86TargetMachine are basically identical.
The *only* thing that's different is the constructor. And that *only*
differs in the is64Bit argument that it passes to the X86TargetMachine
constructor. Replacing the hard-coded 'true' or 'false' with
'Triple(TT).getArch()==Triple::x86_64' makes them *actually* identical.
Can we just ditch the subclasses, move the fields and methods that they
share into the X86TargetMachine class, and use that instead? Or am I
missing something?
In the patch I'm about to post to llvm-commits, I *stop* using the
X86_64TargetMachine subclass entirely, and use X86_32TargetMachine for
the 64-bit target. And the 16-bit target too. And nothing seems to have
broken AFAICT...
--- a/lib/Target/X86/X86TargetMachine.cpp
+++ b/lib/Target/X86/X86TargetMachine.cpp
@@ -24,8 +24,9 @@ using namespace llvm;
extern "C" void LLVMInitializeX86Target() {
// Register the target.
+ RegisterTargetMachine<X86_32TargetMachine> W(TheX86_16Target);
RegisterTargetMachine<X86_32TargetMachine> X(TheX86_32Target);
- RegisterTargetMachine<X86_64TargetMachine> Y(TheX86_64Target);
+ RegisterTargetMachine<X86_32TargetMachine> Y(TheX86_64Target);
}
@@ -74,7 +75,7 @@ X86_32TargetMachine::X86_32TargetMachine(const Target &T,
Stri
const TargetOptions &Options,
Reloc::Model RM, CodeModel::Model CM,
CodeGenOpt::Level OL)
- : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false),
+ : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch())
DL(computeDataLayout(*getSubtargetImpl())),
InstrInfo(*this),
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140106/ab26c06b/attachment.bin>
Jim Grosbach
2014-Jan-06 22:23 UTC
[LLVMdev] Why do X86_32TargetMachine and X86_64TargetMachine classes exist?
Hi David, AFAIK, the answer is basically “because it’s always been that way.” I seem to recall there were some things that were different (data layout string and such), but that could also be parameterized if it hasn’t been already by the recent refactorings, I suppose. -Jim (inline comment below) On Jan 6, 2014, at 7:18 AM, David Woodhouse <dwmw2 at infradead.org> wrote:> These two subclasses of X86TargetMachine are basically identical. > > The *only* thing that's different is the constructor. And that *only* > differs in the is64Bit argument that it passes to the X86TargetMachine > constructor. Replacing the hard-coded 'true' or 'false' with > 'Triple(TT).getArch()==Triple::x86_64' makes them *actually* identical. > > Can we just ditch the subclasses, move the fields and methods that they > share into the X86TargetMachine class, and use that instead? Or am I > missing something? > > In the patch I'm about to post to llvm-commits, I *stop* using the > X86_64TargetMachine subclass entirely, and use X86_32TargetMachine for > the 64-bit target. And the 16-bit target too. And nothing seems to have > broken AFAICT... > > --- a/lib/Target/X86/X86TargetMachine.cpp > +++ b/lib/Target/X86/X86TargetMachine.cpp > @@ -24,8 +24,9 @@ using namespace llvm; > > extern "C" void LLVMInitializeX86Target() { > // Register the target. > + RegisterTargetMachine<X86_32TargetMachine> W(TheX86_16Target); > RegisterTargetMachine<X86_32TargetMachine> X(TheX86_32Target); > - RegisterTargetMachine<X86_64TargetMachine> Y(TheX86_64Target); > + RegisterTargetMachine<X86_32TargetMachine> Y(TheX86_64Target); > } > @@ -74,7 +75,7 @@ X86_32TargetMachine::X86_32TargetMachine(const Target &T, Stri > const TargetOptions &Options, > Reloc::Model RM, CodeModel::Model CM, > CodeGenOpt::Level OL) > - : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false), > + : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch())Think this is missing a "==Triple::x86_64” at the end, yes?> DL(computeDataLayout(*getSubtargetImpl())), > InstrInfo(*this), > > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse at intel.com Intel Corporation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
David Woodhouse
2014-Jan-06 22:33 UTC
[LLVMdev] Why do X86_32TargetMachine and X86_64TargetMachine classes exist?
On Mon, 2014-01-06 at 14:23 -0800, Jim Grosbach wrote:> Hi David, > > AFAIK, the answer is basically “because it’s always been that way.” I > seem to recall there were some things that were different (data layout > string and such), but that could also be parameterized if it hasn’t > been already by the recent refactorings, I suppose.It is *all* now parameterized. The classes are identical apart from that one true/false...> > @@ -74,7 +75,7 @@ X86_32TargetMachine::X86_32TargetMachine(const Target &T, Stri > > const TargetOptions &Options, > > Reloc::Model RM, CodeModel::Model CM, > > CodeGenOpt::Level OL) > > - : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false), > > + : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch()) > > Think this is missing a "==Triple::x86_64” at the end, yes?Nah, I turned that parameter into a Triple::ArchType so that I can pass x86_16 as an option too. See the patch on llvm-commits which adds the x86_16 target. Currently working on a few codegen bugs with building the Linux kernel's 16-bit startup code with 'clang -m16'... -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140106/c5313a98/attachment.bin>
Apparently Analagous Threads
- [LLVMdev] Why do X86_32TargetMachine and X86_64TargetMachine classes exist?
- [LLVMdev] LLVM Win32 Issue
- [LLVMdev] LLVM Win32 Issue
- [LLVMdev] Any suggestion for "Unknown instruction type encountered" error?
- [LLVMdev] Any suggestion for "Unknown instruction type encountered" error?