[PATCH] D54143: [WIP, RISCV] Generate address sequences suitable for mcmodel=medium

James Clarke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 6 15:25:59 PST 2018


jrtc27 added a comment.

In D54143#1321605 <https://reviews.llvm.org/D54143#1321605>, @lewis-revill wrote:

> So my problem is that (if we expand `PseudoLLA` in codegen in the same way as we do in `RISCVAsmParser`) then we lose some flexibility for later addressing uses. Currently I can use the wrapper to do `(WrapperPCRel %pcrel_hi(sym))`, `(WrapperPCRel %got_pcrel_hi(sym))`, `(WrapperPCRel %tls_ie_pcrel_hi(sym))` and `(WrapperPCRel %tls_gd_pcrel_hi(sym))`, whereas with `PseudoLLA` I am limited to just `%pcrel_hi` addressing. The addition of `PseudoLA` would help greatly, but only for PIC, not for TLS, meaning another wrapper would be required anyway. Maybe this is an acceptable approach to use `PseudoLLA` and `PseudoLA` where it fits then add a wrapper later?


For TLS you'd then use the yet-to-be-implemented `PseudoLA_TLS_GD` and `PseudoLA_TLS_IE` (or whatever they end up being called) representing the `la.tls.gd` and `la.tls.ie` macros/pseudo-instructions. Anything you could want to use `WrapperPCRel` will need a corresponding `PseudoFOO` to exist for the assembly parser, so I still fail to see why we would need this extra wrapper. I really like having the exact correspondence between what CodeGen produces and what the equivalent hand-written assembly would be parsed to.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54143





More information about the llvm-commits mailing list