Martin,
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.
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.
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!
Best,
- Eric
On Thu, Jul 1, 2021 at 3:59 PM Martin Storsjö <martin at martin.st> wrote:
> Hey Eric,
>
> It's nice to see this finally drawing closer!
>
> I tried applying the remaining patches for this and building OpenMP (using
> CMake), and the 32 bit version does seem to build fine, but for 64 bit, it
> still fails.
>
> First off, when building for 64 bit, it doesn't seem to realize
it's meant
> to be building for that target unless -m64 is specified manually. In this
> case, CMake and the OpenMP CMake build files end up calling llvm-ml like
> this:
>
> llvm-ml -Domp_EXPORTS -Iruntime/src -I../runtime/src -I../runtime/src/i18n
> -I../runtime/src/include -I../runtime/src/thirdparty/ittnotify -D
> _CRT_SECURE_NO_WARNINGS -D _CRT_SECURE_NO_DEPRECATE -D _WINDOWS -D _WINNT
> -D _WIN32_WINNT=0x0501 -D _USRDLL -win64 -D_M_AMD64 -DOMPT_SUPPORT=0
> -DOMPD_SUPPORT=0 /c /Fo
> runtime/src/CMakeFiles/omp.dir/z_Windows_NT-586_asm.asm.obj
> ../runtime/src/z_Windows_NT-586_asm.asm
>
> I haven't studied the ml.exe/ml64.exe(?) corresponding options, but I
> would expect that -win64 could be made to imply the same as -m64?
>
> Then if I add -m64 manually, building fails like this:
>
> llvm-ml: ../lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:396: void
> {anonymous}::X86MCCodeEmitter::emitMemModRMByte(const llvm::MCInst&,
> unsigned int, unsigned int, uint64_t, bool, uint64_t,
llvm::raw_ostream&,
> llvm::SmallVectorImpl<llvm::MCFixup>&, const
llvm::MCSubtargetInfo&, bool)
> const: Assertion `IndexReg.getReg() == 0 && !ForceSIB &&
"Invalid
> rip-relative address"' failed.
>
>
> // Martin
>
>
>
> On Sun, 13 Jun 2021, Eric Astor wrote:
>
> > Quick update: I've just gotten LLVM-ML to
> > assemble z_Windows_NT-586_asm.asm from the OpenMP runtimes in 64-bit
> mode.
> > Patches required:
> > https://reviews.llvm.org/D104194
> > https://reviews.llvm.org/D104195
> > https://reviews.llvm.org/D104196
> >
> > 32-bit mode will require another patch or two - in particular, it
looks
> like
> > this is the first file that requires support for the @Version
built-in.
> >
> > Best,
> > - Eric
> >
> > On Fri, Oct 30, 2020 at 5:30 AM Martin Storsjö <martin at
martin.st> wrote:
> > On Wed, 28 Oct 2020, Eric Astor wrote:
> >
> > > Martin: would you be able to review some of the current
stack?
> > (Starting
> > > with https://reviews.llvm.org/D89729)
> > > My usual reviewers on this project (Nico & Reid) are a
bit
> > flooded with
> > > other work. I'd be glad to prioritize getting the
OpenMP
> > runtimes building
> > > with llvm-ml once the patches in the current stack land!
> >
> > I'm also rather swamped, and might not be familiar with all
the
> > bits
> > you're touching, but I can see if I can carve out some time
to
> > comment on
> > what I can at least!
> >
> > // Martin
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210701/e0ef45c7/attachment.html>