[PATCH] D53540: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally

[Reid Kleckner via Phabricator via llvm-commits]

rnk added inline comments.


================
Comment at: lib/Target/AArch64/AArch64AsmPrinter.cpp:697
     break;
+    case AArch64::MOVMCSym: {
+    MCSymbol *Sym = MI->getOperand(1).getMCSymbol();
----------------
mgrang wrote:
> efriedma wrote:
> > rnk wrote:
> > > mgrang wrote:
> > > > @rnk Yes, you are correct that the assert here will fail is the localrecover comes before localescape.
> > > > I have tried to model this similar to X86 but the problem is AArch64 cannot do an ADRP on an MCSymbol. So I wasn't sure how to materialize this in the assembler.
> > > > Could you give me some idea on how this can be done?
> > > I guess I've been assuming that you could assemble something like this in a .s file for aarch64, like you can for x86:
> > > ```
> > > main:
> > >   movl $.Lasdf, %eax
> > >   ret
> > > .Lasdf = 1234
> > > ```
> > > 
> > > I would assume that the aarch64 equivalent would be:
> > > ```
> > > main:
> > >   mov d0, #.Lasdf
> > >   ret
> > > .Lasdf = 1234
> > > ```
> > > 
> > > But that doesn't assemble. Does gnu as support that? I don't have an aarch64 binutils build. Maybe llvm-mc should allow mov/movk to accept a symbolic label operand.
> > > 
> > > I don't think we would want to use ADRP, IIRC that's for materializing some PC-relative address, but obviously this isn't that kind of symbol.
> > > Does gnu as support that?
> > 
> > "mov" is pseudo-instruction, but it will expand to at most one instruction (a movz, a movn, or an orr); this is defined in the AArch64 architecture reference.  There is no variable-length pseudo-instruction; if you need a larger value, you have to write out a movz/movk sequence explicitly.
> > 
> > I guess the stack size is currently limited to 256MB on Windows because of the way we emit the prologue on Windows (that's the limit for the alloc_l unwind opcode).  We could maybe teach LLVM to use multiple alloc_l operations, but it's probably reasonable to assume the stack for a function is less than 4GB, so we could emit just two instructions (movz+movk).
> > 
> > For value less than 2^32, gas supports something like the following:
> > 
> > ```
> > movz x0, #:abs_g1:.Lasdf
> > movk x0, #:abs_g0_nc:.Lasdf
> > .Lasdf = 0x12345678
> > ```
> > 
> > If you try this with LLVM, you currently get an error "no resolvable MOVZ/MOVK fixups supported yet", but I think that's straightforward to fix.  (LLVM supports the syntax in general, just not the case where the value is defined in the same object file.)
> GNU does not seem to support it as well.
> ```
> Error: operand 2 should be a SIMD vector element -- `mov d0,#.Lasdf'
> ```
I saw your fixup patches, and this seems like the way to go. At least, this was the most principled way I could come up with to pass information about the stack frame layout of one machine function to another. I didn't want to use a side table and lock in the code generation order dependence.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53540/new/

https://reviews.llvm.org/D53540