[PATCH] D142953: [RISCV] Don't use constantpool for floating-point value if the value can be easily constructed by integer sequence and a floating-point move.

[Alex Bradbury via Phabricator via llvm-commits]

asb added a comment.

Was the motivation for adding the combines mentioned in the patch description to prevent a regression due to this change? In the absence of that, we'd typically try to keep each patch as minimal as possible.

I'm curious if anyone has concerns about cases where converting an int to float might be more expensive that isn't captured in the current cost modelling - from a quick look it does seem likely to be a win unless the int/fp conversion cost is particularly high. Are there other targets that make this same choice? From a quick look at Arm it appears to use an int->float move when doing execute-only codegen but otherwise. Of course it has a wider set of options available in that ISA for efficiently materialising FP constants.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142953