llvm dev - Jul 2021 - LLVM + MASM (llvm-ml)

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

Quick update: I've just gotten LLVM-ML to assemble z_Windows_NT-586_asm.asm
<https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/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/20210613/ef5460ef/attachment.html>

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