<div dir="ltr">Martin,<div><br></div><div>I haven't actually seen the -win64 option for ML(64).EXE documented anywhere - have you? If we can find evidence of what it does for those, we'll of course match it.</div><div><br></div><div>If you want to build with llvm-ml for 64-bit without passing the `-m64` option... all you need to do is run it through a symlink/copy named `llvm-ml64`, the same way you'd need to run Microsoft's "ml64.exe" rather than "ml.exe". I've mimicked the way clang-cl and lld.link dispatch trigger off of the program name, since Microsoft seems to ship the two tools as separate binaries.</div><div><br></div><div>Back to the 64-bit build issues, though - I'll get back to checking on that soon, and see if I can track down the line in the .asm file that triggers that bug. Hopefully it won't be too tricky a fix!</div><div><br></div><div>Best,</div><div>- Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 1, 2021 at 3:59 PM Martin Storsjö <<a href="mailto:martin@martin.st">martin@martin.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Eric,<br>
<br>
It's nice to see this finally drawing closer!<br>
<br>
I tried applying the remaining patches for this and building OpenMP (using <br>
CMake), and the 32 bit version does seem to build fine, but for 64 bit, it <br>
still fails.<br>
<br>
First off, when building for 64 bit, it doesn't seem to realize it's meant <br>
to be building for that target unless -m64 is specified manually. In this <br>
case, CMake and the OpenMP CMake build files end up calling llvm-ml like <br>
this:<br>
<br>
llvm-ml -Domp_EXPORTS -Iruntime/src -I../runtime/src -I../runtime/src/i18n <br>
-I../runtime/src/include -I../runtime/src/thirdparty/ittnotify -D <br>
_CRT_SECURE_NO_WARNINGS -D _CRT_SECURE_NO_DEPRECATE -D _WINDOWS -D _WINNT <br>
-D _WIN32_WINNT=0x0501 -D _USRDLL -win64 -D_M_AMD64 -DOMPT_SUPPORT=0 <br>
-DOMPD_SUPPORT=0 /c /Fo <br>
runtime/src/CMakeFiles/omp.dir/z_Windows_NT-586_asm.asm.obj <br>
../runtime/src/z_Windows_NT-586_asm.asm<br>
<br>
I haven't studied the ml.exe/ml64.exe(?) corresponding options, but I <br>
would expect that -win64 could be made to imply the same as -m64?<br>
<br>
Then if I add -m64 manually, building fails like this:<br>
<br>
llvm-ml: ../lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:396: void <br>
{anonymous}::X86MCCodeEmitter::emitMemModRMByte(const llvm::MCInst&, <br>
unsigned int, unsigned int, uint64_t, bool, uint64_t, llvm::raw_ostream&, <br>
llvm::SmallVectorImpl<llvm::MCFixup>&, const llvm::MCSubtargetInfo&, bool) <br>
const: Assertion `IndexReg.getReg() == 0 && !ForceSIB && "Invalid <br>
rip-relative address"' failed.<br>
<br>
<br>
// Martin<br>
<br>
<br>
<br>
On Sun, 13 Jun 2021, Eric Astor wrote:<br>
<br>
> Quick update: I've just gotten LLVM-ML to<br>
> assemble z_Windows_NT-586_asm.asm from the OpenMP runtimes in 64-bit mode.<br>
> Patches required:<br>
> <a href="https://reviews.llvm.org/D104194" rel="noreferrer" target="_blank">https://reviews.llvm.org/D104194</a><br>
> <a href="https://reviews.llvm.org/D104195" rel="noreferrer" target="_blank">https://reviews.llvm.org/D104195</a><br>
> <a href="https://reviews.llvm.org/D104196" rel="noreferrer" target="_blank">https://reviews.llvm.org/D104196</a><br>
> <br>
> 32-bit mode will require another patch or two - in particular, it looks like<br>
> this is the first file that requires support for the @Version built-in.<br>
> <br>
> Best,<br>
> - Eric<br>
> <br>
> On Fri, Oct 30, 2020 at 5:30 AM Martin Storsjö <<a href="mailto:martin@martin.st" target="_blank">martin@martin.st</a>> wrote:<br>
> On Wed, 28 Oct 2020, Eric Astor wrote:<br>
><br>
> > Martin: would you be able to review some of the current stack?<br>
> (Starting<br>
> > with <a href="https://reviews.llvm.org/D89729" rel="noreferrer" target="_blank">https://reviews.llvm.org/D89729</a>)<br>
> > My usual reviewers on this project (Nico & Reid) are a bit<br>
> flooded with<br>
> > other work. I'd be glad to prioritize getting the OpenMP<br>
> runtimes building<br>
> > with llvm-ml once the patches in the current stack land!<br>
><br>
> I'm also rather swamped, and might not be familiar with all the<br>
> bits<br>
> you're touching, but I can see if I can carve out some time to<br>
> comment on<br>
> what I can at least!<br>
><br>
> // Martin<br>
> <br>
> <br>
></blockquote></div>